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Abstract 

This  document  presents  a  methodology  for  developing  an  organizational  process  model  which 
is  based  on  the  principles  of  object-oriented  design  and  formal  software  engineering  methods.  The 
methodology  begins  with  the  development  of  an  object-oriented  Rumbaugh  model  (27).  The  Rum- 
baugh  model  is  then  formally  specified  in  Z  (Zed)  schemas.  Finally,  the  Z  specifications  are 
translated  into  an  executable  model  in  the  Software  Refinery  Environment™.  This  model  is  de¬ 
scribed  based  on  the  AF  wing  domain  and  developed  in  this  domain.  The  proposed  methodology 
is  then  shown  to  produce  a  very  general  model  which  is  extendable  across  almost  any  domain. 
The  proposed  methodology  is  also  shown  to  be  very  general  and  tailorable  for  specific  domain 
applications. 
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LI  Background 


With  the  increased  capability  and  performance  of  today’s  computer  systems,  many  areas  of 
the  Air  Force  mission  have  been  automated.  These  improvements  have  appeared  in  widespread 
areas  from  the  office  to  the  battlefield.  In  particular,  the  AF  wing  command  and  control  (C2)  area 
can  benefit  from  the  use  of  automated  systems  to  better  evaluate  and  prepare  their  resources  for 
contingencies.  In  today’s  environment,  commanders  could  benefit  by  making  use  of  a  formal  mech¬ 
anism  which  describes  how  a  wing  conducts  its  mission.  This  formal  mechanism  could  help  evaluate 
the  readiness  of  their  wings  and  the  effectiveness  of  various  resource  allocation  configurations. 

Operations  personnel  and  researchers  have  begun  to  realize  that  insufficient  attention  has 
been  given  to  the  area  of  AF  wing  C 2.  This  can  be  seen  from  actions  taken  at  432nd  Fighter 
Wing,  Misawa  AB,  Japan.  The  432nd  initiated  efforts  to  model  the  C 2  activities  of  its  organization 
through  the  use  of  Knowledge  Based  Software  Engineering  techniques  (17).  The  absence  of  a 
formal  representation  of  how  a  wing  performs  its  mission  limits  the  ability  of  wing  decision  makers 
to  evaluate  the  effectiveness  of  the  wing’s  performance.  This  deficiency  means  key  personnel  do 
not  have  the  information  necessary  to  assess  the  impact  of  C 2  automation  on  wing  operations  (12). 
Furthermore,  system  developers  and  maintainers  do  not  have  a  formalized  knowledge  base  to  use 
in  the  specification  and  design  of  new  computer-based  C 2  systems  or  in  the  modification  of  existing 
systems. 

One  way  to  formally  capture  the  knowledge  about  key  objects,  operations,  and  relationships 
relevant  to  AF  wing  C2  is  through  domain  analysis  (28).  Performing  a  domain  analysis  on  an  AF 
wing  would  produce  a  domain  model  consisting  of  information  to  describe  the  domain  structure 
and  rule  bases  necessary  to  capture  domain  knowledge.  Wing  and  headquarters  personnel  could 
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then  use  the  domain  model  in  conjunction  with  other  aspects  of  Knowledge  Based  Software  En¬ 
gineering  (KBSE)  to  analyze  unit  readiness  and  effectiveness  and  to  decide  how  to  best  allocate 
available  resources.  Furthermore,  system  developers  and  maintainers  would  have  a  knowledge  base 
to  establish  the  design  of  new  C2  systems  or  to  aid  in  the  modification  of  existing  systems.  By  using 
formal  methods  of  software  engineering,  the  creation  of  a  domain  model  of  wing  C 2  operations  is 
possible.  This  model  would  serve  as  a  management  tool  for  Air  Force  decision-makers. 

The  KBSE  research  group  at  the  Air  Force  Institute  of  Technology  (AFIT)  continues  to 
conduct  research  into  various  aspects  of  knowledge  based  software  engineering  and  formal  meth¬ 
ods.  Recent  research  by  Hunt  and  Sarchet  developed  a  partial  domain  model  of  AF  wing  C 2 
operations(12,  28).  Their  domain  model  displays  the  basic  relationships  between  a  wing’s  tasks, 
workers,  and  tools.  This  model  along  with  formal  methods  techniques  can  be  used  to  develop  a  tool 
which  would  assist  wing  decision  makers  in  applying  automation  to  the  C 2  process.  This  would 
demonstrate  that  the  formal  methods  of  software  engineering  technology  can  be  effectively  applied 
to  AF  wing  C2.  Additionally,  this  model  could  form  the  basis  for  a  more  general  model  for  use  in 
other  organizations  including  those  outside  of  the  Air  Force. 

1.2  Problem 

Current  methods  for  evaluating  how  a  wing  performs  its  mission  leaves  Air  Force  decision 
makers  with  less  knowledge  about  the  current  status  of  their  commands  than  might  be  possible 
through  a  formal  model.  Key  wing  personnel  could  benefit  from  the  use  of  tools  to  assess  the 
impact  of  C 2  automation  on  wing  operations  and  to  understand  what  requirements  are  best  satisfied 
with  computer-based  C2  systems.  This  might  also  help  system  developers  and  maintainers  in  the 
specification  and  design  of  new  computer-based  C2  systems  or  in  the  modification  of  existing 
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systems.  Therefore,  a  domain  model  of  the  AF  wing  to  use  in  conjunction  with  formal  methods 
might  prove  to  be  be  a  useful  tool  for  aiding  decision  makers  in  the  assessment  of  their  wing.  The 
knowledge  gained  could  also  be  useful  to  system  developers  and  maintainers  as  a  repository  of 
reusable  information  in  the  form  of  applications  and/or  system  specifications. 

This  research  focuses  on  improving  the  AF  wing  domain  model  produced  by  Hunt  and 
Sarchet  (12,  28)  by  developing  more  realistic  representations  for  tasks,  resources,  and  workers. 
The  improved  model  is  then  used  to  better  analyze  the  task  and  resource  assignments  using  formal 
methods.  Metrics  are  defined  to  show  the  extent  to  which  automation  impacts  the  organization. 

Figure  1  shows  an  overall  “big  picture”  of  the  process  used  by  organization  leaders  in  the 
assessment  of  their  organization.  In  this  process,  Create  New/Update  Existing  Task  Model  uses 
the  given  taskings  and  resources  of  an  organization  to  develop  a  new  task  model  or  to  update  an 
existing  task  model  for  that  organization.  Next,  Assign  Resources  to  Tasks  with  Automation  allows 
the  decision  maker  to  consider  different  configurations  of  the  organizational  taskings  with  certain 
tools  being  modeled  as  automation  aids.  Following  that,  the  organizational  leader  can  Analyze 
the  Model  using  organizational  metrics  to  evaluate  the  tasking  assignment.  If  the  automation  of 
specific  tools  indicates  a  significant  impact  on  the  organizational  performance,  then  a  Software 
Requirements  Specification  (SRS)  can  be  developed;  otherwise,  the  resource  to  task  assignment 
model  is  implemented.  The  new  SRS,  if  any,  could  then  be  used  as  input  to  the  Reuse-Based 
Application  Development  Section  of  the  process. 
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Figure  1.  Formalized  Model  Development  Process(32) 
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Problem  Statement: 


The  AF  has  not  made  use  of  existing  knowledge  based  software  engineering  and  formal  methods 
technology  which  could  provide  improved  information  concerning  the  status  of  their  commands  by 
using  the  formal  representation  and  assessment  of  an  AF  wing. 

1.3  Research  Objectives 

The  overall  objective  of  this  research  is  to  show  the  value  of  using  KBSE  and  formal  methods 
in  the  representation  and  assessment  of  an  Air  Force  wing  tasking  model.  The  following  are  specific 
research  objectives: 

•  Analyze  the  previously  existing  model  of  the  AF  wing.  Improve  the  object  model,  dynamic 
model,  and  functional  model  using  the  formal  algebraic  language  Z. 

•  Verify  and,  as  much  as  possible,  validate  the  modified  model. 

•  Extend  the  formal  representation  of  the  model  to  contain  metrics  and  domain-specific  con¬ 
straints. 

•  Translate  the  Z  formal  specifications  to  an  executable  specification  using  the  Software  Refin¬ 
ery  Environment™. 

•  Generalize  the  model  by  identifying  the  domain  specific  constraints  and  dependencies  within 
the  model. 

•  Identify  the  parts  of  the  formal  model  which  would  have  to  be  modified  for  a  new  domain 
and  evaluate  modifying  the  model  for  new  domains  using  formal  methods. 

•  Show  that  formal  methods  can  improve  the  process  of  evaluating  and  assessing  wing  metrics. 
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•  Identify  benefits  provided  by  the  use  of  formal  methods  (e.g.  prototyping,  providing  an 
interface  to  other  platforms,  reuse  of  specifications,  using  new  user  specs  to  derive  a  new 
model). 


1.4  Approach 

To  meet  the  proposed  research  objectives  the  following  approach  was  followed: 

1.  Gained  an  Understanding  of  Knowledge  Based  Software  Engineering  -  Conducted  a  survey 
of  current  software  engineering  literature  to  gain  insight  into  what  KBSE  entails,  to  include 
domain  analysis  and  modeling  and  formal  methods.  This  was  an  essential  step,  for  without 
a  thorough  understanding  of  KBSE,  the  full  potential  of  this  research  could  not  have  been 
realized. 

2.  Reviewed  Operations  Research  Areas  which  Impact  the  Domain  of  Interest  -  Several  areas 
within  the  operations  research  field  have  significant  impact  on  the  current  model  and  the 
interaction  between  its  components.  Identification  and  analysis  of  these  areas  was  necessary 
to  improve  the  current  model  by  injecting  realism.  This  also  led  to  better  overall  system 
metrics. 

3.  Analyzed  Current  Model  -  Performed  an  in-depth  analysis  of  the  current  Air  Force  wing 
domain  model  proposed  by  Hunt  and  Sarchet.  Assessed  its  current  status  and  identified  any 
shortcomings.  Sponsor  feedback  was  not  available  in  this  area. 

4.  Performed  Domain  Modeling  -  Analyzed  past  and  present  work  in  the  C 2  area  to  determine 
applicability  of  this  research  project  and  to  avoid  any  duplication  of  effort.  This  involved  the 
search  for  areas  of  expansion  and  improvement  for  the  current  model  (i.e.  scope,  metrics,  etc.) 
as  well  as  incorporating  expansions  and  refinements  into  the  domain  model  as  appropriate. 

5.  Implemented  Domain  Model  -  The  previous  model  existed  in  Rumbaugh  and  Z  form,  with 
an  Ada  simulation  for  implementation.  The  improved  model  is  implemented  in  a  formal 
executable  language.  This  phase  of  the  research  entailed  reviewing  several  formal  languages 
and  selecting  one  for  use  in  implementation. 

6.  Verified  and  Validated  Domain  Model  -  Domain  experts  were  not  available  to  be  consulted  for 
help  in  validating  the  model  to  determine  whether  it  really  captured  the  behavior  of  the  AF 
wing.  This  would  be  a  necessary  step  in  determining  the  true  reusability  of  the  model  within 
the  AF  domain  and  in  evaluating  the  accuracy  of  this  model.  Verification  of  the  model  was 
done  internally  by  researchers,  and  formal  methods  were  used  as  much  as  possible. 

7.  Identified  Domain  Specific  Constraints  of  the  Model  -  The  model  of  the  AF  wing  was  analyzed 
to  determine  which  portions  of  the  model  are  inherent  to  the  AF  wing  domain.  Once  these 
particular  constraints  were  identified,  they  were  tagged  as  the  parts  of  the  model  which  must 
be  tailored  for  a  particular  domain  of  interest. 
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8.  Generalized  the  Model  -  Within  the  chosen  formal  representation  language,  the  model  was 
abstracted  to  the  necessary  level  to  be  of  general  use.  The  previously  identified  domain 
specific  constraints  were  then  specialized  as  needed  for  a  particular  domain. 

9.  Demonstrated  the  Feasibility  of  Transforming  the  Model  to  Differing  Organizations  -  Using 
the  generalized  model  and  methodology,  an  approach  was  proposed  to  demonstrate  the  reuse 
of  the  methodology  and  model. 

10.  Displayed  Benefits  of  Model  and  Formal  Methods  -  Showed  how  the  domain  analysis  process 
and  formal  development  of  organization  models  could  improve  Air  Force  wing  operations. 
Also  showed  how  formal  methods  lead  to  reusable  models  and  specifications  which  can  span 
several  domains. 


1.5  Initial  Assessment  of  Past  Effort 

This  research  is  based  on  an  initial  research  effort  put  forth  by  Hunt  and  Sarchet  (12,  28). 
Their  research  was  based  on  a  proposal  by  Langloss  entitled  Knowledge  Based  Software  Engineering 
(KBSE)  Support:  A  Formal  Model  of  wing-Level  C2  Applied  to  the  432nd  Fighter  wing,  Misawa 
AB,  Japan  (17).  The  informal  domain  model  of  the  AF  wing  level  command  and  control  tasks  is  a 
first  attempt  to  actually  model  how  a  wing  operates.  Rumbaugh’s  object  modeling  technique  (27) 
was  the  basis  for  the  model,  depicted  in  Figure  2  (11).  The  model  represents  the  following  object 
classes. 


•  Task-  a  piece  of  work  which  must  be  accomplished  by  a  single  person. 

•  Worker-  a  resource  to  accomplish  a  task. 

•  Tool-  a  form  of  automation  to  assist  a  Worker  in  accomplishing  a  task. 
These  objects  are  related  via  the  following  associations. 


•  Assignment-  represents  the  assignment  of  a  specific  Task  to  a  specific  Worker.  Each  assign¬ 
ment  has  the  attributes  time  and  accuracy  which  indicate  the  nominal  time  and  accuracy  to 
which  the  Worker  can  accomplish  the  specific  Task. 
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•  Assigned-  indicates  that  a  specific  Tool  has  been  designated  to  be  used  on  a  specific  Task. 


•  Supports-  indicates  to  what  extent  a  specific  Tool  can  aid  in  the  accomplishment  of  a  specific 
Task.  This  extent  is  indicated  through  the  attribute  level. 


precedes 


Figure  2.  Object  Model 


This  model  demonstrated  the  feasibility  of  analyzing  the  various  configurations  of  Tool  to  Task 
and  Worker  to  Task  assignments.  It  also  exposed  the  difficulty  associated  with  extracting  detailed 
domain  information  from  a  complex  real-world  situation  by  non-domain  experts  (11).  However, 
this  model  appears  readily  extendable  from  modeling  a  particular  Air  Force  wing  to  modeling  any 
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typical  Air  Force  unit,  and  possibly  other  general  organizations.  Figure  3  shows  the  organization 
of  a  typical  Air  Force  wing  and  the  scope  of  the  domain  model  (17).  Further  augmentation  of  the 
Rumbaugh  model  includes  a  formal  model  using  the  formal  programming  language  “Z”  (zed)1  (11). 
This  formal  representation  allows  a  precise  methodology  for  expressing  the  actual  behavior  of  the 
wing  through  the  use  of  formal  model-based  specifications. 


i 

i 


i  Denotes  Scope  of  Thesis 

i 

.  i 

Figure  3.  Typical  wing  Organizational  Chart  (17) 


Although  a  good  start,  this  model  has  some  shortcomings.  Its  representation  in  Z  has  limited 
flexibility.  The  ability  to  generate  executable  code  from  a  Z  formal  model  is  limited.  Therefore,  the 
wing’s  behavior  can  be  modeled,  but  at  this  time  it  cannot  be  observed.  Because  of  this,  Ada  was 


lZ  is  an  formal  specification  language  based  on  predicate  logic,  sets,  and  functions. 
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used  to  the  develop  prototype  tools  for  calculating  unit  metrics.  These  tools  do  not  lend  themselves 
to  rapid  prototyping  or  to  easily  changing  model  behavior. 

The  model’s  metrics  were  unrealistic  and  overly  simplified.  This  was  due  to  the  lack  of  domain 
knowledge  and  the  unavailability  of  domain  experts.  The  time  metric  and  accuracy  metrics  are 
based  solely  on  a  comparison  of  Task  to  Worker  AFSC  and  Worker  skill  level,  respectively.  Further 
refinement  of  these  metrics  are  needed  for  a  more  precise  representation  of  the  organization  (11). 

The  time  and  accuracy  metrics  were  not  thoroughly  validated  by  domain  experts.  This  val¬ 
idation  must  be  done  for  the  domain  model  to  meet  the  user’s  end  needs.  The  domain  experts 
should  specify  any  additional  metrics  which  would  be  useful  in  analyzing  the  effects  of  tool  and 
worker  assignments  on  unit  effectiveness  and  readiness.  The  simplified  metrics  can  lead  to  unreal¬ 
istic  values  for  the  sponsor’s  specified  metrics  of  overall  unit  effectiveness,  unit  efficiency,  and  unit 
readiness  (17). 

The  model  has  the  limitation  of  assigning  only  one  Worker  to  a  Task.  In  reality,  several 
Workers  may  actually  perform  a  Task.  The  model  also  limits  the  assigning  of  only  one  Tool  to  a 
Task.  In  many  cases,  more  than  one  Tool  may  be  desired  to  accomplish  a  Task.  The  model  would 
be  more  realistic  if  it  contained  a  way  to  model  the  assignment  of  multiple  Workers  and/or  Tools 
to  a  single  Task.  The  model  has  neither  the  ability  to  respond  to  real-time  taskings  nor  the  ability 
to  handle  multiple  independent  Tasks.  Both  of  these  situations  would  be  the  norm  in  almost  any 
real-world  situation.  Therefore,  the  model  would  be  greatly  enhanced  if  it  possessed  the  ability  to 
handle  these  situations. 
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1.6  Assumptions 


Prior  to  conducting  this  research  effort  the  following  assumptions  were  made.  First,  sufficient 
domain  knowledge  would  be  available  through  various  sources.  These  sources  included,  but  were 
not  limited  to,  the  sponsors,  documentation,  and  various  domain  experts.  This  knowledge  was 
necessary  for  complete  analysis  of  the  domain  model,  choosing  appropriate  expansion  directions, 
and  validating  the  value  of  the  model.  Also,  the  sponsors  should  provide  access  to  valid  and 
up-to-date  information  on  past,  present,  and  anticipated  C2  domain  analysis  activities.  Another 
assumption  which  was  made  was  that  the  chosen  platforms  would  be  available  for  development  in 
the  formal  development  phase  of  the  research. 

1.7  Scope 

The  modeling  of  the  entire  AF  wing  is  not  the  concern  of  this  research  effort.  The  model’s 
main  focus  is  in  showing  that  automation  can  have  an  impact  on  a  portion  of  the  wing.  The  focus 
is  on  the  fighter  squadron-level  and  does  not  model  all  activities  at  the  group-  or  wing-level.  The 
formal  Refine  implementation  is  limited  to  the  Object  Model.  These  scoping  decision  are  necessary 
to  conduct  the  proposed  research  on  an  organization  of  this  size  within  the  time  available. 

1.8  Organization  of  Thesis 

Chapter  II  contains  a  literature  review  of  KBSE  technology,  domain  modeling,  and  opera¬ 
tions  research  topics  which  are  relevant  to  this  research.  Chapter  III  describes  and  follows  the 
development  of  the  domain  model  which  is  the  focus  of  this  research.  Next,  Chapter  IV  contains 
an  analysis  of  the  methodology  and  the  resulting  model  which  was  developed.  Chapter  V  discusses 
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the  generalizations  and  reusability  of  the  domain  model.  Finally,  Chapter  VI  draws  conclusions 
regarding  this  research  and  offers  some  recommendations  for  future  research  in  this  area. 
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II.  Literature  Review 


2.1  Introduction 

The  focus  of  this  review  is  knowledge  based  software  engineering  (KBSE)  technology  and 
how  this  technology  can  be  applied  to  the  Air  Force  wing.  This  review  begins  with  a  discussion 
of  previous  research  in  the  area  of  domain  analysis  and  modeling.  This  is  necessary  since  domain 
analysis  and  modeling  is  a  fundamental  part  of  establishing  a  knowledge  base.  Next  is  a  review  of 
the  theses  which  form  the  basis  for  this  research.  This  review  also  include  discussion  about  several 
facets  of  operations  research  which  impact  the  research.  Finally,  how  this  all  leads  to  a  specific 
domain  modeling  approach  is  discussed. 

2.2  Systems  Modeling 

“Studies  have  revealed  that  the  most  difficult  part  in  modeling  is  not  the  creation  of  program 
code,  but  rather  the  creation  of  the  system  abstraction  on  which  the  code  is  based”  (21).  The 
current  state  of  system  development  is  very  fragmented  and  conducted  in  an  ad  hoc  manner.  The 
process  of  system  development  needs  to  be  a  fully  integrated  process  which  allows  a  seamless 
transition  from  phase  to  phase  in  the  system  development  process.  Systems  modeling  may  provide 
the  means  to  progress  towards  this  seamless  type  of  development  (7). 

There  are  three  main  areas  in  systems  modeling:  dynamic  performance  modeling,  rapid 
prototyping,  and  executable  specification.  “The  use  of  these  techniques  in  the  development  of 
large,  complex  systems  helps  the  designers  predict  the  behavior  of  the  system,  assess  the  feasibility 
of  the  design,  and  seek  the  optimal  solution  from  the  design  space”  (7). 
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Dynamic  performance  models  are  either  analytic  or  simulation.  If  an  exact  solution  may  be 
obtained  using  a  mathematical  method  then  the  model  is  analytic.  In  a  technical  report  about 
systems  modeling,  Choi  said, 

“Simulation  uses  the  numerical  logic  models  of  a  system  to  examine  its  behavior  over  time 
and  under  different  conditions  and  scenarios.  Executable  specification  is  a  formal  representation  of 
the  system  which  captures  the  functional,  behavioral,  and  implementational  aspects.  Finally,  rapid 
prototyping  is  a  representation  of  the  system  which  bears  closer  resemblance  to  the  final  system 
than  either  dynamic  performance  modeling  or  executable  specification. 

Most  of  the  problems  in  modeling  and  analysis  technology  exist,  not  because  of  a  lack  of 
tools  or  methodologies,  but  because  of  a  lack  of  integration  and  a  failure  to  address  system  level 
issues.  There  are  many  tools  that  address  some  system  problems  or  some  phases  of  system  de¬ 
velopment.  Although  these  tools  alone  are  not  enough  to  develop  all  systems,  when  integrated, 
they  could  provide  many  capabilities  for  system  development.  Currently,  this  integration  has  been 
lacking,  including  the  consistent  usage  of  terms  such  as  modeling,  executable  specification,  and 
prototyping”  (7). 


2.2.1  Fundamentals  of  Modeling.  A  model  is  some  form  of  an  abstraction  of  a  system 
which  can  be  used  to  analyze  certain  aspects  of  the  system.  “Models  may  capture  the  function, 
behavior,  structure,  and/or  implementation  of  a  system”  (7).  In  general,  models  are  hierarchical 
in  nature.  They  are  used  to  develop  a  solution  to  a  problem,  analyze  the  proposed  solution,  and 
optimize  the  solution. 

There  is  no  single  model  which  can  capture  all  aspects  of  an  entire  system.  Models  can  be 
used  to  capture  the  parts  of  the  system  which  need  investigation.  However,  models  suffer  from 
several  problems.  First,  they  tend  to  drastically  increase  in  complexity  in  state-dependent  systems. 
Second,  mapping  from  one  model  to  another  model  is  quite  difficult.  Finally,  it  is  very  difficult  to 
model  the  human  aspect  of  the  system. 

Models  have  suffered  from  lack  of  widespread  use  due  to  their  inherent  complexity.  They 
are  also  limited  in  models’  ability  to  back-annotate  changes  to  the  model.  As  changes  are  made, 
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they  need  to  be  annotated  all  the  way  back  to  the  requirements.  Most  modeling  techniques  fail 
to  accurately  model  the  human  aspects  of  the  system.  The  term  “humanware”  views  humans  as 
resources  which  are  allocated  to  accomplish  system  tasks  (7). 

2.2.2  Executable  Specification.  “Executable  specification,  in  its  most  fundamental  defini¬ 
tion,  captures  the  functional  and  behavioral  descriptions  of  the  system”  (7).  A  complete  executable 
specification  can  serve  as  the  design  specification  and  the  single  representation  of  the  system.  This 
would  be  very  useful  in  system  modification  since  only  one  representation  is  needed  for  system 
modeling  and  design  specification.  All  changes  made  during  modification  would  automatically  be 
reflected  in  the  design  specification.  “An  executable  specification  may  be  used  for  the  evaluation  of 
functional  and  behavioral  correctness  and  consistency.  Executable  specification  is  being  considered 
as  a  promising  approach  to  rapid  prototyping  software”  (7). 

2.2.3  Prototyping.  Recently,  much  use  has  been  made  of  prototyping  to  improve  software 
development.  Software  development  through  the  use  of  prototyping  is  based  on  an  evolutionary 
view  of  software  development.  It  makes  use  of  early  functioning  versions  of  the  system  (19).  A 
prototype  can  be  classified  as  a  model  of  a  system  due  to  the  fact  that  it  is  actually  an  abstraction 
of  the  system.  It  can  contain  very  limited  amounts  of  functionality  or,  on  the  other  extreme,  it 
may  be  fully  functional,  lacking  only  full  testing.  Prototypes  are  different  from  simulation  in  the 
fact  that  simulations  only  mimic  the  behavior  of  the  system  while  prototypes  act  as  the  system. 
Prototypes  are  useful  in  testing  the  system  as  well  as  checking  the  feasibility  of  the  system  and  its 
components  (7).  Prototyping  allows  the  system  to  be  tested  under  its  operating  conditions  with 
limited  capabilities.  Rapid  prototyping  is  a  way  of  prototyping  which  provides  incrementally  added 
functionality  during  system  development  with  a  very  fast  turn  around  time. 
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2.3  Knowledge  Based  Software  Engineering 


Knowledge  Based  Software  Engineering  (KBSE)  refers  to  the  practice  of  developing  and 
maintaining  software  systems  using  sound  engineering  principles,  reusable  software  components, 
domain  models,  and  domain  analysis.  Reuseable  components  constitute  basic  building  blocks  of  a 
domain  model.  By  employing  sound  engineering  principles  in  conjunction  with  domain  modeling 
and  analysis,  software  systems  can  be  developed  rapidly  and  reliably. 

It  has  been  said  that  large  productivity  increases  can  be  seen  by  employing  intelligent 
computer-based  tools  to  aid  in  the  knowledge-intensive  area  of  software  engineering  (1).  KBSE 
will  also  save  time  and  money  by  eliminating  human  introduced  errors  to  the  software  development 
process.  A  vital  part  of  KBSE  is  domain  analysis  and  modeling. 

2.3.1  Domain  Analysis  and  Modeling.  The  initial  area  of  concern  in  creating  a  knowledge 
base  is  capturing  and  representing  the  knowledge  for  the  area  of  interest.  This  is  done  through 
domain  analysis  and  modeling.  A  domain  is  a  particular  area  of  interest  or  study.  The  model  is  a 
formalization  of  the  similarities  and  differences  among  members  of  a  particular  domain.  A  domain 
model  is  the  result  of  conducting  a  domain  analysis  which  consists  of  acquiring  knowledge  about  a 
domain  or  reasoning  about  an  area  of  interest  (domain)  (33). 

Tracz  (30),  McCain  (22),  and  Prieto-Diaz  (25)  have  all  proposed  methods  to  conduct  domain 
analysis  and  modeling.  However,  Prieto-Diaz’s  method  is  the  most  prevalent.  This  method  contains 

the  following  steps: 

1.  Pre-Domain  Analysis 

(a)  Define  Domain 

(b)  Scope  Domain 

(c)  Identify  sources  of  Domain  Knowledge 
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(d)  Define  Domain  Analysis  Goals  and  Guidelines 

2.  Domain  Analysis 

(a)  Identify  Objects  and  Operations 

(b)  Abstract  Objects  and  Operations 

(c)  Classify  the  Abstracted  Objects  and  Operations 

3.  Post-Domain  Analysis 

(a)  Encapsulate  the  Classified  Objects  and  Operations 

(b)  Produce  reusability  Guidelines  (25) 

The  Prieto-Diaz  method  of  domain  analysis  produces  a  model  very  similar  to  the  Rumbaugh 
object  model.  Using  the  Rumbaugh  object  model,  the  members  of  the  domain  are  represented  as 
objects.  Each  object  has  associated  with  it  a  set  of  attributes  or  descriptors.  Rumbaugh  also  uses 
associations,  which  may  have  attributes,  to  represent  the  relationships  or  interactions  between  the 
members  of  the  domain  (27).  The  Rumbaugh  model  is  further  discussed  in  Section  2.5.1. 

2.3.2  Goals  of  a  Domain  Modeling  Methodology.  The  goal  of  a  modeling  methodology 
is  to  develop  an  applicable  model  for  a  particular  domain  of  interest  which  provides  the  user 
with  pertinent  information  regarding  the  organization.  The  methodology  should  provide  a  smooth 
transition  from  the  domain  information  to  the  model  representation.  The  transitions  should  occur 
in  almost  seamless  phases  from  the  developers  viewpoint. 

Hunt  (12)  and  Sarchet  (28)  present  a  basic  domain  model  of  the  Air  Force  wing  structure 
using  a  combination  of  existing  techniques.  Their  approach  is  based  on  a  combination  of  the  domain 
analysis  and  modeling  methods  presented  by  Prieto-Diaz  (25),  Tracz  (30),  and  the  Rumbaugh 

OMT  (27).  The  steps  of  their  technique  follow: 

1.  Define  the  Domain 

2.  Scope  the  Domain 

3.  Identify  Sources  of  Domain  Knowledge 
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4.  Obtain  Domain  Knowledge 

5.  Choose  Model  Representation 

6.  Develop  Domain  Model 

2-4  Formal  Methods  in  Software  Development  and  Maintenance 

What  are  formal  methods?  The  use  of  formal  methods  involves  writing  a  formal  specification 
of  system  requirements  along  with  mathematically  proving  certain  properties  about  these  specifi¬ 
cations.  A  formal  specification  is  a  precise  definition  of  what  the  software  system  is  intended  to 
do.  These  specifications  can  then  be  used  to  mathematically  and  systematically  derive  a  computer 
program  to  fulfill  the  requirements  via  manipulating  the  specifications.  This  program  is  then  at 
least  partially  verifiable  through  mathematical  argument  (9).  It  has  been  said  that  “It  is  hard  to 
fudge  a  decision  when  writing  formal  specifications,  so  if  there  are  errors  or  ambiguities  in  your 
thinking,  they  will  be  mercilessly  revealed”  (9). 

A  method  is  said  to  be  formal  if  it  has  a  sound  mathematical  basis  and,  therefore,  provides 
a  systematic  rather  than  ad-hoc  framework  for  developing  software.  The  acquisition  of  formal 
domain  knowledge  is  difficult  since  it  requires  extensive  collaboration  between  domain  experts  and 
knowledge  engineers.  However,  it  does  provide  many  advantages.  Using  formal  methods  can  help 
to  assure  correctness  from  specification  to  implementation.  It  also  ensures  programs  are  correctly 
implemented  to  fulfill  the  user’s  intentions.  Formal  methods  can  also  be  used  in  conjunction 
with  automated  reasoning  tools,  thus  enabling  the  reuse  of  knowledge-based  software  engineering 
components  (20). 

Formal  methods  can  be  used  in  varying  degrees  within  the  development  of  a  software  sys¬ 
tem.  Specification  and  implementation  are  often  viewed  as  separate  issues.  First,  the  user  totally 
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specifies  the  system  requirements  in  a  formal  language  at  a  high  level  of  abstraction,  free  from  any 
implementation  language  details.  Then,  as  a  separate  development  phase,  the  program  is  generated, 
taking  into  consideration  the  implementation  details. 

The  program  implementation  of  the  specifications  might  be  done  totally  automatically  via 
an  automatic  programming  tool,  semi- automatically  through  the  use  of  a  transformation  system, 
or  manually  using  software  engineering  techniques.  However  the  system  is  developed,  the  program 
arrives  at  the  implementation  through  the  use  of  the  specification  of  requirements  and  verifying  that 
the  implementation  is  valid  for  the  requirements.  It  should  be  noted  that  the  steps  of  specification 
and  implementation  may  be  somewhat  intertwined.  If  limitations  are  noticed  in  requirements 
during  development  of  the  implementation,  the  requirements  analysis  phase  should  be  revisited. 

By  modifying  user  specifications  and  redeveloping  the  entire  system  from  the  formal  specifica¬ 
tions,  maintenance  becomes  redevelopment  and  is  easier  to  perform.  If  the  formal  specification  and 
the  semantics  used  to  implement  the  specifications  are  in  an  executable  form,  then  the  specifications 
have  an  observable  behavior  and  the  implementation  can  be  validated  from  the  specifications.  This 
enables  the  specification  to  be  utilized  as  a  prototype  software  system.  The  formal  specifications 
are  much  easier  to  reuse  than  specific  implementations  in  code.  One  of  the  biggest  benefit  of  formal 
methods  is  that  formal  specifications  lead  to  the  ability  to  automate  the  software  development 
process  or  at  least  gives  rise  to  the  use  of  an  automated  software  development  assistant  (2). 

It  must  be  realized  that  the  use  of  formal  methods  does  not  guarantee  that  a  software  system 
is  perfect  because  it  cannot  be  guaranteed  that  the  user’s  specifications  are  always  correct.  This 
is  due  to  the  behavior  of  the  real  world.  The  real  world  cannot  always  be  modeled  and  does 
not  always  react  as  modeled.  However,  using  formal  methods  does  provide  some  degree  of  proof. 
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One  can  be  mathematically  sure  that  the  system  fulfills  the  specified  requirements,  which  is  very 
useful.  Formal  proof  techniques  allow  the  errors  in  the  specifications  to  be  exposed.  This  enables 
the  identification  of  errors  early  in  the  development  cycle  which  equates  to  less  costly  fixes  to 
the  system.  More  benefits  provided  by  using  formal  methods  are  fitness  for  purpose,  ease  of 
construction,  ease  of  maintainability,  and  better  visibility.  Formal  methods  increase  the  chances 
of  the  right  software  being  built  by  ensuring  interaction  between  the  system  designer  and  the  user 
regarding  the  system  specifications  when  the  specifications  are  being  formalized.  This  leads  directly 
to  decreased  development  and  maintenance  costs  (9). 

2.5  Model  Representation 

2.5.1  The  Rumbaugh  Object  Modeling  Technique.  Object-oriented  modeling  and  design 
is  a  fairly  new  concept  which  places  emphasis  on  the  organization  of  software  models  making  use 
of  real-world  concepts.  This  concept  is  based  on  a  fundamental  construct  called  the  object.  The 
object  combines  both  data  structure  and  behavior  into  a  single  entity.  The  Rumbaugh  Object 
Modeling  Technique  (OMT)1  is  based  on  the  object-oriented  modeling  and  design  concept.  All 
phases  of  development,  to  include  analysis,  design,  and  implementation,  are  covered  by  the  OMT. 

Since  the  Rumbaugh  OMT  model  is  depicted  using  a  basic  set  of  graphical  representations 
and  is  based  on  well-known  object-oriented  foundations,  it  is  extendable  across  domains  and  allows 
modeling,  design,  and  implementation  using  a  consistent  set  of  object-oriented  concepts  and  nota¬ 
tions.  In  the  OMT  methodology,  three  distinct  models  are  used  to  describe  a  system:  the  object 
model,  the  dynamic  model,  and  the  functional  model. 

1The  Rumbaugh  Object  Modeling  Technique  will  hereby  be  referred  to  as  OMT  and  the  resulting  model  the 
Rumbaugh  model. 
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2.5.2  Object  Model  The  object  model  is  composed  of  objects  and  the  associations 
between  the  objects.  Object  diagrams  describe  the  structure  of  the  objects  in  the  system  to 
include  their  identity,  their  relationships  to  other  objects,  and  their  attributes.  An  object  is  a 
distinguishable  entity  while  an  object  class  represents  a  group  of  objects  with  similar  attributes, 
common  operations,  and  common  relationships.  An  object  class  is  represented  with  a  rectangle 
and  attributes  along  with  their  type  declarations.  Figure  4  is  an  example  of  an  object  class  and 
individual  object  instances  of  the  object  class. 

(Automobile) 

1979 
Camaro 

Object  Class  with  Attributes  Objects  with  Attribute  Values 

Figure  4.  Object  Class  and  Object  Instances 

2.5.2. 1  Associations  and  Links.  The  relationships  between  object  classes  are  estab¬ 
lished  using  associations.  An  association  describes  the  group  of  potential  links  between  all  of  the 
instances  of  the  related  object  classes.  Figure  5  is  an  illustration  of  this  example. 


Association 

Figure  5.  Association  and  Link  Examples 

In  Figure  5,  there  is  a  solid  black  circle  on  one  end  of  the  association.  This  is  the  method  used  to 
specify  the  multiplicity  of  the  association  between  objects.  This  representation  allows  associations 
to  be  from  one-to-one  up  to  many-to-many.  It  also  is  used  to  represent  required  and  optional 
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membership  in  the  links  and  associations.  Table  1  describes  the  multiplicity  representations  in  the 
Rumbaugh  OMT  method  along  with  the  formal  representation  using  Z . 

Table  1.  Multiplicity  Representation  (10) 


Domain 

Range 

Specification 

Symbol 

Rumbaugh 

IATeX 

m:n 

either 

either 

Relation 

A  <-►  B 

A_ 

• - • 

\rel 

n:l 

optional 

optional 

Partial  Function 

A  -»■  B 

Jv_ 

• - 0 

B_ 

\pfun 

n:l 

required 

optional 

Total  Function 

A->  B 

A_ 

• - 

B_ 

\fun 

n:l 

optional 

required 

Partial  Surjection 

A  -+»  B 

T 

ht - o 
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2. 5. 2. 2  Dynamic  Model  The  dynamic  model  represents  the  system  as  it  changes 
over  time  by  specifying  and  implementing  the  system’s  control.  This  is  modeled  using  state  dia¬ 
grams.  It  is  used  to  describe  the  the  sequence  of  operations  in  a  system  without  consideration  for 
what  the  operations  do,  what  they  operate  on,  or  how  they  are  implemented.  All  actions  in  the 
state  diagram  correspond  to  functions  in  the  functional  model.  Figure  6  displays  a  simple  dynamic 
model  of  an  Automobile. 
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Figure  6.  Automobile  Dynamic  Model 
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2. 5. 2. 3  Functional  Model  The  functional  model  describes  how  the  data  within  the 
system  is  changed.  This  part  of  the  model  uses  data  flow  diagrams.  The  functional  model  captures 
what  the  system  actually  does  and  is  not  concerned  with  when  or  how  the  system  does  it.  It 
describes  the  parts  of  the  system  which  change  values  through  functions,  mappings,  and  functional 
dependencies.  The  functions  within  the  functional  model  correspond  to  actions  within  the  dynamic 
model  and  operate  on  the  objects  within  the  object  model  (27).  Figure  7  is  an  example  of  a  simple 
functional  model. 


student_schedule 


registration 


Figure  7.  Functional  Model 

2.5.3  The  Z  Language.  One  manner  in  which  to  formally  capture  the  information  con¬ 
tained  within  the  Rumbaugh  OMT  model  is  through  the  use  of  a  formal  specification  language  such 
as  Z  (29).  Z  is  a  formal  language  used  to  abstractly  specify  a  system  using  mathematical  constructs 
to  represent  the  system’s  states  and  operations.  This  type  of  mathematical  model  allows  the  system 
developer  to  reason  about  the  correctness  of  the  system  and  its  specified  behavior.  Since  it  is  based 
on  fundamental  mathematical  principles,  the  system’s  behavior  can  be  abstractly  represented  and 
the  system  specifications  produced  are  precise,  unambiguous,  concise,  and  amenable  to  proof  (31). 
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The  Z  language  is  used  to  formally  define  the  specifications  of  a  system  in  a  mathematically 
based  notation.  A  system  is  described  using  modules  called  schemas  which  contain  data  definitions 
and  constraints  on  the  data  (24).  The  following  Z  schema  is  a  representation  of  the  Automobile  in 
Figure  4. 
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2.6  Modeling  Organizational  Activities 

A  process  is  simply  a  group  of  related  activities  for  the  accomplishment  of  a  particular  task. 
A  process  model  is  used  to  describe  all  of  the  objects,  activities,  and  the  relationships  between 
them.  A  process  model  done  correctly  can  directly  support  the  understanding,  evaluation,  and 
improvement  the  process  (21).  A  process  model  has  many  uses  within  an  organization.  There  are 
several  methods  for  modeling  an  organization  and  it  activities.  These  methods  vary  and  are  based 
on  goals  of  the  model  as  well  as  the  organization. 

2.6.1  Generic/ Specific  Modeling.  Research  by  Lung,  et  al,  presents  the  concepts  and  prac¬ 
tical  experiences  of  generic/specific  modeling.  Generic/Specific  (GS)  modeling  is  a  domain  analysis 
approach  to  produce  a  discrete-event  simulation  in  the  manufacturing  domain.  Also  presented  is 
a  meta- model  based  on  the  generic/specific  approach  from  the  software  engineering  perspective. 
Also  discussed  are  the  domain  analysis  lessons  learned  from  the  approach.  Traditional  simula¬ 
tion  modeling  suffers  one  of  the  same  problems  as  traditional  software  development-  the  lack  of 
reuse.  Modelers  tend  to  view  each  simulation  as  a  new  project  and  start  to  build  the  model  from 
scratch  (21). 
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One  of  the  main  advantages  to  the  GS  approach  is  that  it  reduces  the  amount  of  time  and 
workload  of  the  simulation  modeler.  This  is  accomplished  through  the  ability  to  select  a  model 
from  a  number  of  generic  models  and  modify  the  selected  model  as  necessary  as  opposed  to  building 
a  new  model  from  scratch.  A  generic  model  is  a  one  designed  to  meet  a  basic  set  of  objectives  for 
selected  applications.  A  group  technology  (GT)  classification  scheme  is  used  to  classify  or  group 
these  generic  models  (21).  After  the  selection  of  a  generic  model,  the  modeler  can  then  input  more 
specific  detailed  data  to  derive  a  specific  model.  This  model  is  then  interpreted  and  linked  to 
form  an  executable  model.  This  is  done  by  the  SIMAN  architecture  which  is  a  simulation  program 
processor  (21). 

This  approach  has  proven  to  be  a  very  effective  example  of  reuse  within  the  discrete-event 
simulation  domain.  Reuse  is  accomplished  by  allowing  the  modeler  to  build  a  simulation  model 
despite  the  fact  he  or  she  possesses  only  basic  skills  and  knowledge.  This  reusability  leads  directly 
to  increased  productivity,  reduced  costs,  improved  quality,  and  enhanced  reliability.  This  approach 
of  providing  model  selection  and  modification,  as  opposed  to  building  a  model  from  the  ground  up, 
also  avoids  errors  in  creation  and  coding  (21). 

This  approach  integrates  bottom-up  and  top-down  analysis  with  domain  modeling.  Objects, 
operations,  and  relationships  of  systems  are  identified  through  the  use  of  a  bottom-up  analysis. 
Knowledge  structures  or  domain  architectures  are  built  and  whole  model  reuse  (not  just  code 
reuse)  is  promoted  through  the  application  of  top-down  synthesis  (21). 

2.6.2  Business  Process  Reengineering .  The  fundamental  goal  of  business  process  reengi¬ 
neering  is  to  identify  and  to  correct  fundamental  deficiencies  in  the  business  process.  This  should 
be  done  prior  to  and  opposed  to  only  identifying  tasks  for  automation.  Once  the  deficiencies  have 
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been  corrected,  automating  the  appropriate  tasks  will  further  improve  the  process.  Basically,  the 
idea  is  to  avoid  using  technology  for  technology’s  sake  (23). 

The  beginning  steps  in  business  process  reengineering  are  quite  similar  to  the  total  quality 
management  philosophy  which  examines  processes  to  identify  non-value  or  limited  value  added 
steps.  However,  business  process  reengineering  actually  redefines  the  process  based  upon  the  find¬ 
ings.  The  overall  goal  of  business  process  reengineering  is  to  eliminate  the  assembly-line,  sequential 
mentality  and  promote  the  idea  of  parallel  process  thinking  where  many  people  have  access  to 
available  information  simultaneously  (23). 

This  idea  of  business  process  reengineering  is  needed  because  most  businesses  have  had  their 
processes  in  place  for  the  most  part  since  early  in  their  conception.  As  the  need  arose  for  process 
change,  the  institutions  simply  adapted  instead  of  redesigning  the  overall  process.  Then  with 
the  inception,  or  inclusion,  of  automation,  existing  tasks  were  identified  to  be  automated  without 
reevaluating  the  overall  process.  This  resulted  in  a  faster  process  but  not  necessarily  a  better 
process  (23). 

Another  step  which  must  be  accomplished  early  in  business  process  reengineering  is  to  move 
the  business’  tasks  from  a  sequential  mode  into  parallel  structured  tasks.  This  can  be  accomplished 
by  having  separate  units  within  the  organization  which  perform  the  same  tasks  or  by  having  the 
separate  units  perform  different  tasks  which  eventually  come  together.  This  parallel  structure  will 
allow  for  greater,  more  efficient,  output  of  the  overall  process  (23). 

2.6.3  Job- Shop  Development  Model.  Current  software  development  models  are  based  on 
the  waterfall  paradigm  of  software  development.  This  paradigm  has  specific  and  differing  phases 
for  the  software  to  progress  through  on  its  way  to  completion.  These  types  of  models  do  not  lend 
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to  accounting  for  software  rework  which  is  caused  by  errors,  requirements  changes,  and  software 
enhancements  (18). 

A  better  way  to  model  software  development  is  through  the  use  of  a  model  based  on  the 
job  shop  concept.  This  approach  has  been  successfully  used  in  industry  to  model  manufacturing 
processes.  This  approach  will  allow  a  more  detailed  representation  of  software  development  by 
breaking  each  ongoing  project  into  smaller  batches  and  breaking  the  batches  into  even  smaller 
jobs.  This  will  allow  the  view  that  any  individual  parts  of  the  software  system  may  be  in  differing 
stages  of  development  at  any  one  time.  This  is  a  much  better  view  of  the  real  world  of  software 
development  (18). 

Many  organizations  which  are  involved  in  the  development  of  several  similar  projects  often 
divide  their  staff  among  the  projects.  The  job-shop  model  is  suitable  for  such  organizations,  espe¬ 
cially  if  they  have  a  well  defined  software  development  process.  The  particular  job  shop  model  can 
be  calibrated  using  “appropriate  probability  distributions  for  items  such  as  personal  productivity, 
sick  leave,  and  vacation,  and  for  establishing  scheduling  priorities  (18).” 

In  a  job-shop  model,  a  certain  number  of  tasks  are  processed  through  a  certain  number  of 
stations.  Each  station  is  made  up  of  machines  and/or  people.  The  tasks  involved  all  have  their 
own  independent  processing  requirements,  a  processing  order,  and  a  scheduling  priority.  This 
concept  can  be  easily  applied  to  the  software  development  environment.  Software  modules  are  all 
subject  to  most  of  the  following  stages:  requirements  analysis,  design,  coding,  testing,  fielding,  and 
maintenance.  In  fact,  the  modules  may  undergo  iterations  within  the  stages.  The  job-shop  view 
of  software  development  sees  each  software  project  as  a  group  of  batches,  which  are  related  jobs, 
and  a  job  as  a  specific  software  item  needing  to  be  accomplished.  This  model  depicts  each  worker 
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individually,  which  leads  to  a  stochastic  network  of  jobs  and  batches  being  routed  through  the  life 
cycle  phases  of  software  development  (18). 

Prior  to  the  start  of  any  new  project,  the  project  is  assigned  a  priority.  Also,  the  number  of 
anticipated  batches  is  estimated.  Next,  the  processing  path  is  specified  and  finally,  the  intra-  and 
inter-batch  dependency  chains  are  specified.  Nonproductive  times  for  workers  are  represented  by 
filler  jobs.  A  probability  distribution  is  used  to  generate  the  filler  jobs.  An  overall  scheduler  must 
be  used  to  maintain  the  list  of  available  jobs  and  their  related  information,  along  with  the  workers 
and  the  tasks  they  are  qualified  to  accomplish  (18). 

Probability  distributions  are  used  to  estimate  when  and  where  errors  will  occur  and  to  where 
the  batch  in  error  must  return.  Calibrating  the  model  involves  much  time  accounting.  Each 
worker’s  productivity  must  be  recorded  for  the  correct  probability  distribution  in  the  model.  Also, 
nonproductive  times,  error-capture  rates,  the  phase  to  which  rework  is  sent,  maintenance  times 
and  efforts,  etc.  must  be  recorded  and  predicted.  The  data  recorded  is  analyzed  under  a  best-fit 
analysis  and  found  to  fit  a  gamma-distribution.  The  initial  overhead  incurred  in  setting  up  such  a 
model  is  costly.  The  required  set-up  time  is  proportional  to  the  complexity  of  the  work  flows,  the 
number  of  workers,  and  the  number  of  ongoing  projects  (18). 

Many  organizations  will  find  that  the  job  shop  model  has  the  potential  to  be  an  effective 
simulation  tool  for  project  effort  prediction.  It  provides  the  flexibility  to  model  stations  through 
which  a  task  must  pass  as  a  person,  group,  or  people  using  machines.  This  will  allow  researchers 
to  “investigate  the  effect  of  new  technologies  by  making  appropriate  assumptions  about  model 
components  (18).” 
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The  job-shop  model  has  several  limitations.  First,  a  large  amount  of  historical  data  may  be 
needed  for  calibration  of  the  model.  Second,  much  effort  is  required  for  the  initial  setup.  Third, 
the  tasks  of  the  scheduler  are  so  intensive  that  the  processing  time  is  lengthy,  which  makes  testing 
and  debugging  time  consuming.  An  improved  scheduling  algorithm  could  lead  to  faster  processing 
times  (18). 

2.6.4  Improving  an  Industrial  Software  Process.  The  technology  which  supports  software 
development  has  made  impressive  strides  in  the  recent  past;  however,  estimating  and  improving 
software  development  is  still  difficult.  This  shortcoming  has  led  to  much  research  in  the  area  of 
software  process  improvement.  An  assessment  of  a  mid-sized  Italian  company  found  that  “[while]  it 
was  reasonably  easy  to  identify  the  technical  areas  where  improvement  is  needed  (e.g.  configuration 
management  and  requirements  engineering),  it  is  much  more  difficult  to  understand  how  to  conduct 
the  analysis  of  a  company  in  order  to  identify  its  organizational  and  strategical  deficiencies,  and 
how  to  identify  and  propose  reasonable  changes  and  improvement  actions  accordingly  (3).” 

The  proposed  method,  by  Bandinelli,  for  process  modeling  is  based  on  the  SLANG  (SPADE 
Language)  process  modeling  language.  SLANG  is  based  on  a  Process-centered  Software  Engineering 
Environment  called  SPADE  (Software  Process  Analysis,  Design  and  Enactment).  SLANG  is  a 
domain  specific  language  for  modeling  software  processes.  “SLANG  is  based  on  high-level  petri 
nets  and  is  given  formal  semantics  in  terms  of  a  translation  scheme  from  SLANG  objects  into  ER 
nets,  a  mathematically  defined  class  of  high-level  Petri  nets  that  provide  the  designer  with  powerful 
means  to  describe  concurrent  and  real-time  systems  (3).”  However,  petri  nets  have  been  shown  to 
be  very  complex  for  even  the  smallest  of  projects. 
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2.6.5  IDEF  Models.  The  ICAM  Definition  Methodology  (IDEF)  is  based  on  Integrated 
Computer  Aided  Manufacturing  (ICAM).  The  construction  of  an  IDEF  model  has  been  said  to 
be  the  initial  component  in  a  comprehensive  process  modeling  effort.  The  initial  IDEF  model 
is  IDEFO  which  is  developed  to  model  a  wide  variety  of  systems  to  include  hardware,  software, 
and  people  performing  activities.  The  IDEFO  model  has  three  major  components—  diagrams,  text, 
and  a  glossary.  All  three  components  are  cross-referenced  to  each  other.  The  diagrams  consist  of 
boxes  and  arrows.  The  boxes  represent  functions  and  the  arrows  represent  either  inputs,  outputs, 
controls,  or  mechanisms.  An  active  verb  phrase  which  represents  the  function  is  used  to  identify 
the  box.  “Inputs  (I)  enter  the  box  from  the  left,  are  transformed  by  the  function,  and  exit  the  box 
to  the  right  as  an  output  (O).  A  control  (C)  enters  the  top  of  the  box  and  influences  or  determines 
the  function  performed.  A  mechanism  (M)  is  a  tool  or  resource  which  performs  the  function.  The 
interfaces  are  generally  referred  to  as  the  ICOM’s  (16).” 

“IDEF3  was  created  specifically  to  model  the  sequence  of  activities  performed  in  a  manufac¬ 
turing  system.  An  IDEF3  model  enables  an  expert  to  communicate  the  process  flow  of  a  system 
through  defining  a  sequence  of  activities  and  the  relationships  between  those  activities  (16).”  The 
IDEF3  process  description  language  has  two  main  components,  the  process  flow  description  and 
the  object  state  transition  network  description.  IDEF3  diagrams  are  developed  by  cross-referencing 
the  two  main  components  (16). 

The  IDEF3  model  uses  three  components  to  make  up  the  process  flow  description-  units  of 
behavior  (UOB),  links,  and  junction  boxes.  Each  activity  or  function  occurring  in  the  process  is 
represented  using  a  UOB.  The  UOB’s  relationships  with  each  other  are  modeled  with  three  types 
of  links.  These  links  are  precedence  links,  relational  links,  and  object  flow  links.  “Precedence  links 
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express  simple  temporal  precedence  between  UOBs.  Relational  links  highlight  the  existence  of  a 
relationship  between  two  or  more  UOBs,  however,  no  temporal  constraint  is  implied.  Object  flow 
links  provide  a  mechanism  for  capturing  object  related  constraints  between  UOBs  and  carry  the 
same  temporal  semantics  as  a  precedence  link  (16).”  The  branching  within  a  process  is  modeled 
using  and ,  or,  and  exclusive-or  junction  boxes. 

The  IDEF3  model  uses  object  state  transition  network  (OSTN)  diagrams  to  model  object 
state  changes  relative  to  the  process  flow  description.  OSTN  diagrams  are  composed  of  nodes 
and  arcs.  Each  object  in  the  model  may  or  may  not  have  associated  with  it  an  OSTN  diagram. 
The  arcs  of  the  diagram  represent  the  possible  state  transition  paths  that  may  be  taken  by  the 
object.  The  transition  arcs  may  have  associated  with  them  certain  scenarios,  UOBs,  or  other  OSTN 
diagrams.  The  components  of  the  IDEF3  model  can  also  be  decomposed  similarly  to  the  IDEFO 
model.  There  do  exist  some  formal  methods  for  analyzing  the  structure  of  an  IDEF  model,  one  of 
which  is  described  in  (16). 

2.7  Domain  Specific  Issues 

The  particular  domain  of  interest  for  this  research  is  the  AF  wing.  Within  this  domain,  there 
exist  several  issues  which  are  unique  to  the  AF  wing.  The  AF  wing  structure  is  basically  a  worker- 
task  type  domain.  This  type  of  relationship  leads  directly  to  literature  which  is  concerned  with 
representing  and  classifying  both  tasks  and  workers  as  well  as  describing  the  assignment  of  workers 
to  tasks.  Classification  is  a  basic  method  used  in  many  domains  to  aid  in  the  understanding  of  a 
particular  system;  however,  there  is  no  existing  method  which  can  be  used  for  all  problems  (21). 
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2. 7. 1  Task  Classifications.  To  improve  the  attributes  associated  with  tasks,  it  is  important 
to  be  able  to  identify  tasks  which  are  somehow  related  and  to  group  the  tasks  accordingly.  Certain 
groups  of  tasks  are  inherently  similar,  while  other  tasks  are  drastically  dissimilar.  Tasks  may  be 
grouped  along  many  boundaries.  These  boundaries  include  area  of  specialty,  difficulty  presented, 
and  mental  and  physical  abilities  required  just  to  name  a  few.  Huo  and  Kearns  state  “It  is  necessary 
to  classify  all  jobs  into  clusters,  or  job  families,  in  accordance  with  the  similarity  among  their 
requirements  (13)”.  These  clusters  or  groups  would  help  identify  meaningful  task  attributes  for  use 
in  many  domain  models. 

Huo  and  Kearns  also  suggest  matching  employees  to  jobs  based  on  three  input  files.  The  first 
file  represents  the  individual  employee’s  qualifications  and  contains  performance  ratings,  techni¬ 
cal/functional  skills  and  associated  ratings,  educational  background,  career  history,  and  personal¬ 
ity/attitude  attributes.  The  second  file  holds  the  individual  employee’s  constraints  which  include 
preferences  and  interests,  mobility  limitation,  language  limitations,  current  job  level,  and  current 
pay  level.  The  third  and  final  file  is  the  job  profile  file  which  contains  job  requirements,  prior  in¬ 
cumbents,  job  cluster  ID,  and  search  criteria.  A  search  mechanism  is  used  to  evaluate  all  employees 
for  an  open  job  position.  This  search  is  based  on  the  data  in  the  three  files.  Making  the  best  set 
of  worker-to-task  assignments  is  a  desired  outcome. 

2.7.2  Worker  Attributes.  Any  useful  measures  that  can  identify  and  predict  the  amount 
of  work  which  can  be  accomplished  by  an  individual  on  a  certain  task  would  be  very  valuable  in 
domain  modeling.  “The  military  has  interest  in  performance  measurement  for  many  of  the  same 
reasons  as  business:  to  support  proper  personnel  decisions  and  enhance  the  output  and  operation 
of  the  organization  (6).” 
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In  1989,  the  Human  Resources  Directorate  of  Armstrong  Laboratory  began  a  study  of  the  job 
performance  of  workers.  The  goal  of  the  study  was  to  identify,  develop,  and  evaluate  the  current 
technologies  used  in  the  measurement  of  job  performance.  This  research  led  to  the  area  of  productive 
capacity  (PC).  PC  could  be  used  to  aid  in  the  forecasting  of  aptitude  and  experience  levels  needed 
by  a  worker  in  order  to  accomplish  a  given  task  or  quantity  of  work.  The  findings  of  this  research 
concluded  that  experience  level  was  the  most  important  influence  on  the  PC  of  an  individual  (6). 
Pre-employment  testing  is  an  efficient  and  effective  way  to  predict  job  performance.  “Cognitive 
ability  or  intelligence  testing  seems  to  be  the  best  known  predictor  of  job  performance  (4).” 

Knowing  the  abilities  of  particular  workers  would  also  be  a  valuable  attribute  within  the 
domain  model.  Research  by  Faneuff  (8)  produced  a  study  of  the  effects  of  mechanical  aptitude  and 
job  experience  on  the  performance  of  aerospace  ground  equipment  (AGE)  mechanics.  Their  job 
performance  was  expressed  as  PC  and  was  found  using  estimated  performance  times  on  selected 
job  tasks.  This  research’s  PC  measures  were  obtained  using  airmen  within  the  career  field  of 
AGE  completing  50  typical  tasks.  Aptitude  measures  were  the  actual  scores  of  the  airmen  on 
the  Armed  Services  Vocational  Aptitude  Battery  (ASVAB).  This  study  indicated  that  experience 
is  a  much  more  reliable  predictor  of  PC  than  was  aptitude.  It  also  found  no  indication  of  an 
aptitude/experience  interaction  (8).  Therefore,  the  experience  level  and  productive  capacity  of 
a  worker  warrant  consideration  as  valuable  worker  attributes  in  a  domain  model.  This  seems  to 
indicate  that  the  associations  between  worker  and  job  objects  might  benefit  from  derived  attributes 
which  describe  the  amount  of  time  and  expected  accuracy  between  a  particular  worker  and  a 
particular  job. 
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FaneufFs  research  suggests  the  use  of  three  distinct  competency  levels  -  fastest  possible,  aver¬ 
age  or  normal,  and  slowest  possible  (6),  and  indicates  that  a  job  might  benefit  from  the  additional 
attributes  average  time,  best  time ,  and  worst  time  to  complete. 

A  recent  study  of  the  effects  of  mechanical  aptitude  and  job  experience  on  the  performance 
of  AGE  mechanics  found  that  the  job  performance  of  the  mechanics  was  influenced  by  both  the 
experience  level  and  aptitude  of  the  particular  worker. 

2.7.3  Job  Performance  Measures.  The  ability  to  measure  the  performance  of  a  worker 
on  a  particular  job  could  lead  to  useful  worker  attributes  within  the  domain  model  as  indicated 
in  AHRL-TR-87-15  (14).  This  report  contains  a  description  of  the  job  performance  measurement 
classification  scheme  the  military  currently  uses.  It  describes  the  Air  Force  Human  Resources 
Laboratory’s  (AFHRL)  research  program  aimed  at  the  development  of  individual  job  performance 
measures.  It  also  describes  a  classification  scheme  which  was  developed  by  the  AFHRL.  Analysis 
of  this  study  indicates  that  the  ability  to  measure  job  performance  accuracy  would  be  a  valuable 
attribute  in  the  worker  to  task  association  of  the  Air  Force  wing  domain  model  (14). 

2. 7.4  Skills  Classification.  Categorizing  human  resources  is  a  very  difficult  task.  Human 
talents  are  characterized  by  high  degrees  of  complexity  and  heterogeneity.  They  cannot  be  easily 
classified  in  the  same  manner  as  normal  capital  resources.  Classifying  the  qualities  of  a  human 
resource  are  a  prerequisite  for  making  use  of  a  computer  platform  to  aid  in  the  decision  making 
process.  This  classification  process  is  a  major  obstacle  for  the  managers  of  personnel.  Employee’s 
qualification  data  can  consist  of  education  background,  work  experience,  age,  sex,  and  race.  These 
qualifications  tend  to  come  in  the  form  of  “packages”  of  a  set  of  these  qualities.  The  diversity  of 
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the  various  strengths  and  weaknesses  within  the  packages  make  it  hard  to  evaluate  the  individual 
human  resource  and  to  make  objective  comparisons  between  individuals  (13). 

It  is  also  difficult  to  specify  the  combination  of  skills,  knowledge,  and  attributes  which  are 
desirable  for  a  person  to  have  so  that  he  or  she  will  be  successful  at  a  given  task.  Many  feel  that 
employee  performance  and  attitude  are  important  characteristics.  These  attributes  are  often  very 
subjective.  However,  these  have  been  used  to  predict  future  job  performance  with  more  accuracy 
than  education  and  possessed  skills  (13). 

2.7.5  Unit  Readiness.  The  sponsor  of  this  research  desires  the  ability  to  assess  the  impact 
of  automating  certain  aspects  of  the  AF  wing’s  mission  on  certain  overall  organizational  metrics. 
One  of  the  metrics  specifically  proposed  was  unit  readiness.  A  review  of  this  area  led  to  several 
reports  concerning  overall  unit  readiness.  However,  these  reports  were  primarily  Army  and  Navy 
outlooks.  Based  on  these  reports,  the  following  discusses  overall  unit  readiness  and  how  it  can  be 
determined. 

2.7.5. 1  Initial  Unit  Readiness  Dimensions.  In  an  initial  assessment,  Research  Tri¬ 
angle  Institute  defines  unit  readiness  as  “The  capability  of  an  Army  unit  to  perform  the  mission 
for  which  it  is  organized.”  Their  initial  definition  was  based  on  nine  dimensions.  These  dimensions 
are  (15): 

1 .  Equipment  -  Does  the  unit  have  all  of  the  necessary  equipment  on  hand  and  is  the  equipment 
operational? 

2.  Personnel  Strength  -  Do  the  authorized  and  actual  assigned  slots  of  the  unit’s  personnel  match 
in  both  job  and  rank? 

3.  Training  Status  -  How  well  trained  are  all  personnel  in  mission  essential  tasks?  Rating  is 
based  on  the  time  necessary  to  have  all  personnel  trained  to  proficiency. 
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4.  Supervision  -  How  proficient  are  the  skills  of  the  officers  and  non-commissioned  officers  in  the 
organization? 

5.  Collective  Performance  -  How  well  do  groups  of  workers  perform  collective  tasks? 

6.  Unit  Performance  -  How  well  does  the  entire  unit  perform  on  normal  requirements  and  to 
impromptu  taskings? 

7.  Higher  Level  Support  -  How  much  support  does  the  unit  receive  from  higher  level  and  external 
organizations? 

8.  Cohesion  -  How  much  overall  loyalty,  pride,  and  positive  interaction  do  the  members  of  the 
unit  possess? 

9.  Stability  -  How  stable  are  the  personnel  who  make  up  the  unit? 

2. 7.5.2  Modified  Unit  Readiness  Dimensions.  Through  data  collection,  independent 
analysis,  and  review,  the  initial  dimensions  were  modified  to  the  following  group  which  are  more 
specific  classifications  of  the  initial  dimensions. 


1.  Adherence  to  Standards 

2.  Ammunition,  Supplies,  Materials,  and  Other  Equipment 

3.  Care  and  Concern  for  Families 

4.  Care  and  Concern  for  Soldiers 

5.  Cohesion  and  Teamwork 

6.  Communication  Within  Unit 

7.  Cooperation/Coordination  with  Other  Units 

8.  Emergent  Leadership 

9.  Higher  Echelon  Support 

10.  Leadership 

11.  Mission  Performance 

12.  Personnel  Capabilities 

13.  Personnel  Deployability 

14.  Physical  Fitness  Program 

15.  Physical  Security/Vigilance 

16.  Training  Program 

17.  Unit  Weapons 
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18.  Vehicles/Transportation 


However,  this  report  did  not  detail  how  these  individual  dimensions  are  used  to  calculate  an 
overall  unit  readiness  factor  or  even  what  scale  is  used  for  the  measurement. 

Based  on  this  research,  it  seems  that  the  unit  readiness  metric  is  based  on  measures  which 
cannot  be  assessed  or  impacted  by  the  use  of  automation  to  complete  a  job  or  task.  However,  a  good 
starting  point  in  assessing  this  metric  within  the  current  model  could  easily  be  based  on  Personnel 
Strength  and  equipment  readiness.  Almost  every  organization  in  existence  has  a  manning  plan  for 
the  organization  which  states  the  number  of  persons  needed  for  the  organization  to  accomplish  its 
mission  along  with  the  specific  qualifications  each  should  possess.  By  simply  comparing  the  actual 
personnel  to  the  needed  personnel  an  initial  readiness  metric  could  be  established.  This  metric  can 
easily  be  added  to  the  object  model  by  adding  a  Manning  object  which  has  a  readiness  attribute. 
This  attribute  could  be  derived  from  a  comparison  of  the  Workforce  to  the  Manning  required  for 
the  Organization. 

2.8  Conclusion 

The  focus  of  this  review  was  knowledge  based  software  engineering  (KBSE)  technology  and 
how  this  technology  can  be  applied  to  the  Air  Force  wing.  This  review  concluded  with  a  specific 
domain  analysis  and  modeling  approach  to  be  used  in  this  research.  Also  discussed  were  many 
ideas  related  to  process  modeling. 

This  review  has  identified  several  areas  of  potential  improvement  in  not  only  the  model  but 
the  process  to  be  used  in  developing  the  model.  First,  several  key  attributes  were  identified  which 
will  help  improve  the  realism  of  the  objects  within  the  model.  Also,  the  relationships  between 
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the  objects  can  be  improved  using  the  information  gained  by  the  review.  These  include  the  the 
relationship  between  the  tool  and  job  object  classes  and  the  worker  and  job  object  classes.  These 
improvements  are  discussed  in  detail  in  Chapter  III. 

2.8.1  Role  of  Domain  Analysis  and  Modeling  in  this  Research.  There  are  many  aspects 
to  domain  analysis  and  modeling  which  have  been  brought  to  light  through  this  literature  review. 
Based  on  the  research  and  information  gathered,  the  following  domain  modeling  approach  is  fol¬ 
lowed  in  the  remainder  of  this  thesis.  This  approach  is  loosely  based  on  the  Job  Shop  model  and 
the  information  contained  in  Section  2.6.3. 

•  Describe  the  objects  and  their  attributes  as  thoroughly  as  possible 

•  Identify  and  describe  all  relationships/associations  between  the  objects 

•  Compose  a  Rumbaugh  model  of  the  system 

•  Fully  describe  the  Rumbaugh  model  in  Z  notation 

•  Transform  the  Z  notation  into  executable  Refine 

•  Verify  and  validate  the  model 

•  Generalize  the  model 

2.8.2  Model  Development  Methodology.  This  literature  review  has  helped  in  the  devel¬ 
opment  of  a  methodology  to  aid  in  the  development  of  a  domain  model  for  the  AF  wing.  This 
proposed  methodology  is  composed  of  three  distinct  phases.  The  first  phase  includes  the  gather¬ 
ing  of  all  the  necessary  domain  information  and  putting  it  into  the  Rumbaugh  OMT  model.  The 
first  transition,  to  phase  two,  is  to  capture  the  desired  behavior  of  the  model  in  a  formal  context 
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through  the  use  of  the  Z  schemas.  This  step  helps  facilitate  the  correct  frame  of  mind  for  the  model 
developer  to  achieve  the  third  and  final  phase  of  development-  the  Refine  transformation.  This 
phase  requires  the  developer  to  think  functionally  rather  than  procedurally  to  develop  a  model’s 
behavior  and  allow  the  Refine  environment  to  capture  the  behavior.  Once  a  model’s  specifications 
have  been  defined  within  the  Refine  environment,  modification  of  the  model’s  behavior  is  achieved 
through  a  simple  change  of  specifications,  allowing  the  Refine  environment  to  handle  the  execution 
details.  This  approach  is  fairly  generic  and  allows  for  the  development  of  similar  models  based  on 
the  same  types  of  organizations,  that  is,  organizations  which  inherently  are  composed  of  Worker , 
Task ,  and  Tool  objects,  with  assignments  of  these  objects.  Chapter  III  follows  the  implementation 
of  this  modeling  approach  and  examines  the  resulting  model. 
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III.  Developing  the  Domain  Model 


3.1  Introduction 

In  this  chapter,  the  AF  wing  domain  is  analyzed  and  a  domain  model  is  developed  using  the 
approach  discussed  in  Section  2.8.1.  The  new  model  is  based  on  the  initial  model  developed  by 
Hunt  and  Sarchet  and  the  analysis  of  their  model.  In  this  chapter,  the  goals  of  the  model  and  the 
approach  for  developing  the  model  are  detailed.  The  Rumbaugh  model,  Z  specifications,  and  the 
Refine  implementation  are  also  presented. 

3.2  Goals  of  the  Model 

When  developing  a  domain  model,  it  is  necessary  to  know  how  the  model  is  to  be  used  and 
what  information  is  needed  from  the  model.  This  model  will  be  used  to  assess  overall  organization 
metrics  such  as  unit  readiness,  unit  effectiveness,  and  unit  efficiency.  Other  uses  of  the  model  will 
include  evaluating  the  impact  of  automation  tools  on  a  fully  assigned  Project  and  evaluating  the 
status  of  Tasks  and  Projects.  The  model  will  also  be  useful  in  the  assessment  of  various  proposed 
schedules  for  individual  Worker ,  Tool ,  and  Job  assignments  and  their  impact  on  the  Organization. 
The  model  should  also  be  easily  modified  for  use  by  other  organizations. 

3.2.1  Modeling  Issues.  There  are  many  different  and  difficult  issues  that  arise  in  the 
development  of  any  real-world  domain  model.  Issues  include  what  values  to  assign  to  the  time  and 
accuracy  attributes  of  a  job  given  that  a  certain  Worker- Job  assignment  has  been  made.  Another 
issue  is  how  to  model  the  impact  of  assigning  a  tool  to  a  job  and  the  effect  it  has  on  the  time  and 
accuracy  attributes  of  the  job.  Also,  many  of  the  higher  level  objects  of  a  domain  model  may  have 
many  derived  attributes;  the  derivation  of  these  attributes  must  be  dealt  with  correctly. 
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3.2.2  Model  Representation.  A  domain  model  is  the  result  of  a  domain  analysis.  There¬ 
fore,  it  is  important  to  choose  a  model  representation  up  front.  The  informal  model  is  based  on 
Rumbaugh’s  OMT  (27),  briefly  described  in  Section  2.5.1,  including  Rumbaugh’s  three  specified 
components:  the  object  model,  the  dynamic  model,  and  the  functional  model.  The  Rumbaugh 
model  is  then  converted  into  the  Z  schema  language.  The  properties  of  Z  allow  for  a  formal 
approach  to  describing  the  model  through  the  use  of  predicate  logic  and  mathematical  symbol 
descriptions.  This  is  followed  by  the  transformation  of  the  Z  specifications  into  executable  Refine 
constructs,  a  model  closer  to  the  actual  programming  language  of  the  desired  final  product. 

3.2.3  Model  Maintainability.  Modification  and  maintenance  of  the  model  should  be 
quick  and  easy.  Changing  the  behavior  of  the  model  should  simply  involve  changes  to  the  formal 
specifications.  An  evolutionary  or  incremental  approach  to  system  development  should  be  simple 
to  implement  with  the  availability  of  a  functional  prototype  system  to  check  behavior  throughout 
the  development. 

3.2.4  Executable  Platform  Analysis.  During  this  research,  an  assessment  was  made  of 
the  abilities  of  several  KBSE  tools  available  at  AFIT.  These  platforms  included  the  transforma¬ 
tion  system  by  Wabiszewski  (31),  Kestrel  Institutes  SpecWare  (5),  and  Refine  (26).  Wabiszewski’s 
transformation  system  needs  further  development  to  actually  transform  Z  into  Refine  code.  It  pro¬ 
vides  the  abstract  syntax  tree  needed;  however,  the  transformations  stop  at  the  function  signatures. 
To  utilize  this  tool  in  the  context  desired  would  require  the  completion  of  the  transformations  nec¬ 
essary  to  fully  define  the  function  bodies.  This  effort  was  deemed  beyond  the  scope  of  this  research 
effort.  The  SpecWare  environment  is  still  in  the  process  of  further  refinement  and  was  assessed 
to  be  beyond  the  ability  of  the  researcher.  The  Refine  environment  is  the  most  feasible  to  use  in 
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demonstrating  the  value  of  the  formal  model  in  the  development  and  assessment  of  an  organization 
model. 

3.2.5  Refine.  Refine  directly  supports  many  of  the  common  data  types  encountered  to 
include  integer ,  real ,  boolean,  symbol,  sets,  sequences,  maps,  objects  and  many  more.  An  object 
in  Refine  is  represented  as  a  class.  A  class  is  declared  as  a  variable  of  the  type  object-class.  All 
objects  must  be  declared  in  the  realm  of  some  superclass,  therefore,  the  highest  level  objects  are 
declared  as  a  subtype  of  the  superclass  user-class.  Each  attribute  of  an  object  is  defined  as  a  map 
from  the  object  to  the  attribute  domain. 

3.3  Methodology  for  Developing  the  Model 

One  goal  is  to  make  the  model  more  representative  of  the  real-world  through  further  domain 
analysis.  A  thorough  analysis  of  the  domain  is  necessary  for  a  successful  model  to  be  implemented. 
This  requires  an  understanding  of  the  domain  of  interest  and  access  to  domain  experts.  The 
operations  research  literature  exposed  many  potential  areas  for  improvement.  The  approach  used 
in  this  research  to  develop  a  domain  model  of  an  AF  organization  is  based  on  Rumbaugh’s  OMT 
and  the  principles  of  Job  Shop  Scheduling  as  discussed  in  Section  2.6.3. 

3.3.1  Rumbaugh  Model  Development.  The  first  step  in  the  approach  is  to  fully  describe 
all  of  the  objects  within  the  domain.  In  the  domain  of  the  AF,  this  includes  many  objects,  all  of 
which  need  attributes  which  describe  their  properties  and  states.  The  next  step  in  the  approach  is 
to  identify  all  relationships  which  might  exist  between  the  objects  within  the  domain.  These  rela¬ 
tionships  are  then  transformed  into  associations  and  further  analyzed  to  determine  the  attributes 
of  the  associations  if  necessary.  After  all  of  the  objects  and  association,  along  with  their  attributes, 
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are  been  identified,  a  Rumbaugh  object  model  is  developed.  Based  on  the  object  model  and  domain 
information,  the  dynamic  and  functional  models  are  then  developed.  This  completes  the  first  phase 
of  the  development. 

3.3.2  Z  Formalization  of  the  Object  Model.  The  three  parts  of  the  Rumbaugh  model 
(the  object  model,  dynamic  model,  and  functional  model)  fully  describe  the  model;  however,  they 
do  not  formally  show  any  correctness  of  behavior  or  exhibit  any  from  of  executability.  The  Z 
language  was  chosen  to  use  as  an  intermediate  step  in  the  formalization  of  the  domain  model  prior 
to  implementing  the  model  in  Refine.  Although  not  directly  executable,  the  Z  language  gives  the 
ability  to  mathematically  specify  the  behavior  of  the  model  using  a  wide  range  of  mathematical 
constructs.  The  descriptions  include  the  object  and  association  attributes  along  with  the  predicates 
which  fully  describe  the  behavior  of  the  objects  and  associations  within  the  overall  model.  To 
facilitate  an  understanding  of  the  overall  model,  it  is  easiest  to  start  with  descriptions  of  the 
most  basic  objects.  In  many  schemas  the  attributes  and  predicates  are  relatively  simple  and  self- 
explanatory.  However,  in  some  of  the  more  complex  schemas  the  predicates  are  sometimes  confusing 
and  require  further  explanation. 

3.3.3  Transforming  Z  to  Refine.  Now  that  the  model’s  behavior  is  fully  defined  in  the  Z 
specifications,  phase  three  is  ready  to  begin. 

3. 3. 3.1  Defining  Objects  in  Refine  as  Classes.  Using  the  Software  Refinery  Envi¬ 
ronment  to  develop  the  model  starts  with  a  bottom-up  approach.  The  first  step  is  to  implement  all 
of  the  objects  in  the  Rumbaugh  and  Z  models  as  Refine  objects.  This  involves  creating  a  separate 
file  for  each  object.  The  object  itself  needs  to  be  declared  as  a  variable  of  type  object-class.  The 
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attributes  of  each  object  are  then  declared  as  mappings  from  the  object  to  the  defined  attribute 
type. 

Once  all  of  the  objects  are  declared,  the  methods  for  accessing  and  updating  the  attributes 
are  added  to  each  object  file.  This  is  done  through  the  use  of  the  function  construct  along  with  the 
transform  construct. 

3. 3. 3. 2  Defining  Associations  in  Refine  as  Objects.  Defining  associations  within 
the  model  starts  at  the  highest  level  object,  in  this  case,  the  Organization.  This  is  done  since  the 
associations  are  between  objects  within  the  model  and  the  Organization  has  visibility  into  all  of 
the  objects  in  the  system  either  directly  or  indirectly.  The  associations  are  defined  as  a  mapping 
from  the  Organization  to  a  set  of  links.  Each  individual  link  is  initially  declared  as  a  subtype  of 
user-object.  The  link  is  then  given  attributes  which  designate  the  objects  it  associated  between 
along  with  any  link  attributes  attached  to  the  association.  Next,  a  specialized  object  is  declared 
for  each  association  to  represent  a  set  of  these  links.  This  is  to  allow  for  specialized  operations 
unique  to  each  particular  association.  These  association  set  objects  are  declared  as  subclasses  of 
Container. 

The  Container  superclass  allows  for  generic  operations  which  are  needed  for  all  of  the  asso¬ 
ciations  such  as  Addltem,  Removeltem,  Getltem,  etc. 

3. 3. 3. 3  Adding  Interaction  Among  Objects.  Within  the  highest  level  aggregate 
object,  the  Organization ,  aggregate  methods  or  functions  between  objects  can  be  defined.  Since 
the  aggregate  objects  contain  many  set  and  sequence  constructs,  it  is  convenient  and  powerful  to 
use  the  built-in  set  and  sequence  operations  provided  through  the  Refine  environment.  By  making 
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use  of  the  set  and  sequence  former  notation,  many  powerful  functions  can  be  defined  and  utilized. 
This  allows  the  environment  to  do  many  mundane  tasks  such  as  go  through  a  set  of  objects  and 
return  the  ones  which  meet  a  certain  criteria  without  the  need  to  write  code  to  loop  through  the  set 
and  check  for  the  condition  while  storing  the  correct  members  in  a  temporary  set  to  return.  The 
Refine  environment  takes  care  of  the  “how”;  all  the  designer  supplies  is  the  “what”.  The  following 
is  an  example: 

%%  Functions  to  find  and  assign  all  of  the  tasks  and  jobs  of  an  organization 
function  Getorg-taskset (oi :  Organization^ 

TRUE  — >  org-taskset (ol)  = 

reduce (union,  {ptask.set (pi)  I  (pi:  Project)  pi  in  org-projectset(ol)}) 

In  this  example,  it  is  specified  that  the  set  to  return  is  the  set  of  all  Tasks  which  are  in  the  ptask-set 
(a  Project’s  set  of  Tasks )  for  all  of  the  Projects  which  are  in  the  Organization’s  set  of  Projects. 

3.4  AF  Wing  Domain  OMT  Model 

3.4.I  Analysis  of  Existing  Model.  The  organizations  within  the  AF  structure  are  in¬ 
herently  composed  of  Projects  to  complete,  a  Workforce  to  complete  the  Projects,  and  Tools  with 
which  to  aid  the  accomplishment  of  particular  parts  of  the  Projects.  A  domain  analysis  of  the  AF 
Organization  has  identified  uses  of  a  domain  model  in  the  assignment  of  Workers  to  accomplish 
Jobs  and  Tools  supporting  the  accomplishment  of  these  Jobs. 

Changes  to  the  model  include  adding  an  approach  to  calculating  overall  unit  readiness  and 
the  addition  of  an  intermediate  level  work  unit  to  allow  for  a  Project  object  to  be  composed  of 
Task  objects  which  are  further  composed  of  Job  objects.  The  Hunt  and  Sarchet  model  was  limited 
to  assigning  a  single  Worker  to  a  Task  and  single  Tool  to  a  Task.  In  reality,  several  Workers  may 
actually  perform  a  Task  in  a  given  Project  and  several  Tools  may  also  be  used.  This  is  accounted 
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for  through  the  intermediate  level  Task  object  which  is  composed  of  one  or  more  Job  objects  which 
have  been  defined  as  the  smallest  unit  of  work  to  be  accomplished  by  a  single  Worker.  The  modified 
model  also  provides  for  intermediate  level  metrics  to  use  in  the  derivation  of  higher  level  objects’ 
attributes. 

The  initial  model  depicted  in  Figure  2  contained  only  two  parts:  the  object  model  and  the 
functional  model.  This  initial  model  was  modified  to  include  more  objects,  more  associations,  and 
a  dynamic  model.  These  modifications  were  done  to  increase  realism  and  to  increase  the  usefulness 
of  the  model.  This  model  might  then  be  extendable  to  more  general  organizations  beyond  the  AF. 

3.4.2  Object  Model  Description.  The  preliminary  object  model  was  modified  based  on  the 
knowledge  and  understanding  of  the  objects,  attributes,  associations,  and  operations.  Refinement 
of  the  object  model  was  an  iterative  process,  as  with  most  analysis  and  design  projects.  Feedback 
from  the  research  sponsor  and  domain  experts  was  not  readily  available.  Refinements  were  based 
on  domain  documentation  as  analyzed  by  local  personnel. 

In  phase  one  of  the  development  process,  the  Rumbaugh  model  was  developed.  The  improved 
object  model  is  shown  in  Figure  8,  without  object  attributes. 

3.4.2. 1  Object  Identification.  Based  on  a  thorough  domain  analysis,  the  following 
objects  were  identified: 

•  Organization  The  highest  level  aggregate  object  with  derived  attributes  for  organizational 
level  metrics. 

•  Project  A  composition  of  Task  objects  which  represents  an  overall  entity  of  work  from  start 
to  finish. 

•  Task  An  intermediate  level  unit  of  work  composed  of  Job  objects  used  to  collect  intermediate 
level  metrics  through  derivable  attributes. 

•  Job  The  smallest  unit  of  work  which  can  be  accomplished  by  a  single  Worker  with  or  without 
the  use  of  a  Tool . 
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Figure  8.  Object  Model  (without  attributes) 


•  Workforce  The  total  set  of  all  of  the  Workers  in  an  Organization. 

•  Worker  The  object  used  to  represent  each  individual  worker  within  the  Organization. 

•  Toolset  The  total  set  of  all  of  the  Tool  objects  in  an  Organization. 

•  Tool  The  object  used  to  represent  each  individual  tool  within  the  Organization. 

•  ManningPlan  The  set  of  all  Positions  in  an  Organization. 

•  Position  The  object  used  to  represent  each  individual  position  within  the  Organization. 


3.4.2.2  Worker.  The  Worker  object  is  a  resource  which  composes  the  Workforce. 
The  experience,  education,  and  aptitude  attributes  were  added  as  a  result  of  research  concerning 
worker  attributes  and  productive  capacity  as  discussed  in  Section  2.7.2.  The  attributes  of  the 
Worker  object  are: 

•  name:  the  name  of  the  individual  Worker 

•  afsc:  the  Worker’s  Air  Force  Specialty  Code 

•  skilLJevel:  the  skill  level  held  by  the  Worker 

•  availability:  Boolean  indicator  of  whether  the  Worker  is  available  for  assignment  or  is  cur¬ 
rently  assigned  to  a  Job 

•  experience:  indicator  of  the  amount  of  experience  a  Worker  has  in  this  afsc 

•  education:  the  education  level  of  the  Worker 

•  aptitude:  the  evaluated  aptitude  of  the  Worker 

34.2.3  Workforce.  The  Workforce  object  is  composed  of  a  set  of  Worker  objects 
and  has  the  following  derived  attribute: 

•  force_readiness:  an  assessment  of  the  overall  readiness  of  the  Workers  in  the  Workforce 

34.24  Tool.  The  attributes  of  the  Tool  object  are: 

•  name:  the  name  of  the  Tool 

•  status:  the  current  condition  of  the  Tool,  either  go  or  no  go 

•  availability:  Boolean  indicator  of  whether  the  Tool  is  available  to  assist  in  accomplishing  a 
Job  or  is  currently  in  use  and  unavailable 

•  afsc_set:  the  set  of  afscs  for  Worker  objects  who  are  able  to  use  the  Tool 

•  skilLJevel:  the  desired  skill  level  of  the  Worker  objects  who  may  use  the  Tool 


49 


3. 4.2. 5  ToolSet.  The  ToolSet  object  is  composed  of  a  set  of  Tool  objects  and  has 
the  following  attribute: 

•  tool  readiness:  an  assessment  of  the  overall  readiness  of  the  tools  in  the  ToolSet 

3. 4- 2.6  Position .  The  attributes  of  the  Position  object  are: 

•  number:  the  number  of  the  Position 

•  afsc:  the  afsc  desired  for  the  Position 

•  skilLlevel:  the  desired  skill  level  for  the  Position 

3. 4- 2.1  ManningPlan.  The  ManningPlan  is  composed  of  a  set  of  Position  objects 
and  has  no  attributes. 

3. 4- 2. 8  Job.  The  Job  object  is  the  smallest  piece  of  work  defined  within  the  model 

and  has  the  following  attributes: 

•  name:  the  identifier  of  the  particular  Job 

•  priority:  the  priority  of  the  Job  relative  to  the  other  jobs  in  the  Task 

•  afsc„set:  the  set  of  afscs  which  are  allowed  to  perform  the  Job 

•  complexity:  the  difficulty  of  the  Job  from  zero  (least  difficult)  to  100  (most  difficult) 

•  skilLlevel:  the  Worker  skill  level  required  to  perform  the  Job 

•  status:  the  status  of  the  Jo&,  either  ready,  waiting,  in-process,  or  finished 

•  inputs:  a  list  of  data  items  which  must  be  available  before  the  Job  can  be  started 

•  outputs:  a  list  of  items  which  have  been  accomplished  after  the  Job  is  finished 

•  average_time:  the  amount  of  time  required  for  an  average  Worker  to  accomplish  the  Job 
without  the  use  of  a  Tool 

•  best_time:  the  optimal  amount  of  time  for  a  Worker  to  accomplish  the  Job  without  the  use 
of  a  Tool 

•  worst_time:  the  greatest  amount  of  time  required  for  the  least  qualified  Worker  to  accomplish 
the  Job  without  the  use  of  a  Tool 

•  automated_time:  the  amount  of  time  required  to  accomplish  the  Job  if  it  is  completely  auto¬ 
mated 

•  average_accuracy:  the  amount  of  accuracy  for  an  average  Worker  accomplishing  the  Job 
without  the  use  of  a  Tool 
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•  best_accuracy:  the  optimal  accuracy  for  a  Worker  accomplishing  the  Job  without  the  use  of 
a  Tool 

•  worst_accuracy:  the  lowest  accuracy  for  the  least  qualified  Worker  to  accomplish  the  Job 
without  the  use  of  a  Tool 

•  percent-complete:  a  percentage  of  how  complete  the  Job  is  at  the  current  time 

•  start-time:  the  time  when  the  Job  actually  started  or  is  scheduled  to  start 

•  end_time:  the  time  when  the  Job  actually  finished  or  is  scheduled  to  finish 

•  accuracy:  the  calculated  accuracy  of  the  Job  based  on  how  it  is  accomplished  and  the  at¬ 
tributes  of  the  objects  which  accomplish  it  (i.e.  Tool  and  Worker) 

•  time:  the  calculated  amount  of  time  required  to  accomplish  the  Job  based  on  how  it  is 
accomplished  and  the  attributes  of  the  objects  which  accomplish  it  (i.e.  Tool  and  Worker) 

The  Job  object  includes  an  attribute  name  which  indicates  the  particular  Job.  The  aver¬ 
age,  best,  and  worst  time  and  accuracy  attributes  were  added  to  improve  the  actual  assignment 
of  time  and  percentage  attributes  of  the  qualified-for  association  between  Workers  and  Jobs.  At¬ 
tributes  start— time  and  stop_ time  were  added  to  the  Job  object  to  facilitate  the  actual  timing  of 
the  accomplishment  of  a  Job. 

The  time  and  accuracy  attributes  of  a  Job  are  determined  based  on  how  the  Job  is  to  be 
accomplished,  either  with  or  without  a  Worker  and  with  or  without  a  Tool,  or  if  the  Job  is  auto¬ 
mated.  These  attributes  are  further  impacted  by  the  attributes  of  the  Tool  and  Worker  if  they  are 
involved  in  the  accomplishment  of  the  Job.  A  highly-skilled  or  well-educated  Worker  will  have  the 
impact  of  decreasing  the  time  attribute  of  the  Job  if  assigned  to  accomplish  the  Job  and  vice  versa. 
The  accuracy  attribute  can  be  affected  in  a  similar  manner  with  a  highly  skilled  Worker  having  the 
effect  of  increasing  the  accuracy.  The  assigning  of  a  Tool  to  aid  in  the  accomplishment  of  a  Task 
has  a  similar  effect  on  the  time  and  accuracy  attributes  of  the  Job  based  on  the  attributes  of  the 
Supports  association. 
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3. 4-2-9  Task.  The  Task  object  is  defined  as  a  set  of  one  or  more  Job  objects.  The 
Task  object  includes  an  attribute  name  to  identify  individual  tasks.  The  attributes  of  the  Task 
object  are: 

•  name:  the  identifier  of  the  particular  Task 

•  priority:  the  priority  of  the  Task  relative  to  the  other  Tasks  in  the  Project 

•  status:  The  current  status  of  the  Task 

•  inputs:  a  derivable  list  of  items  which  must  be  available  or  accomplished  before  the  Task  can 
begin 

•  outputs:  a  derivable  list  of  items  which  are  available  or  have  been  accomplished  after  the 
Task  is  completed 

•  time_so_far:  amount  of  time  spent  accomplishing  the  Task  up  to  the  current  time 

•  percent-complete:  a  derivable  percentage  of  how  complete  the  Task  is  so  far 

•  number_ofLjobs:  the  total  number  of  Jobs  which  comprise  the  Task 

•  jobs_complete:  the  number  of  Jobs  which  comprise  the  Task  which  have  been  accomplished 

•  start-time:  the  time  when  the  Task  was  actually  started 

•  end  time:  the  time  when  the  Task  was  actually  finished 

•  walL.time:  total  time  elapsed  to  complete  the  Task 

•  total-time:  sum  of  all  Job  times  in  the  Task 

3.4.2.10  Project.  The  Project  object  is  defined  as  a  set  of  one  or  more  Task  objects. 
The  Project  object  includes  an  attribute  name  to  identify  individual  Projects.  The  attributes  of 
the  Project  are: 

•  name:  the  identifier  of  the  particular  Project 

•  priority:  the  priority  of  the  Project  relative  to  all  other  projects  in  the  Organization 

•  status:  The  status  of  the  Project 

•  time_so_far:  amount  of  time  spent  accomplishing  the  Project  up  to  the  current  time 

•  number_oiLtasks:  the  total  number  of  tasks  which  comprise  the  Project 

•  tasks_complete:  the  number  of  tasks  which  comprise  the  Project  which  have  been  accom¬ 
plished 

•  percent-complete:  a  derivable  percentage  of  how  complete  the  Project  is  so  far 

•  number_of_jobs:  the  total  number  of  Jobs  which  comprise  the  Project 

•  jobs_complete:  the  number  of  Jobs  which  comprise  the  Project  which  have  been  accomplished 
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•  start_time:  the  time  when  the  Project  was  actually  started 

•  end_time:  the  time  when  the  Project  was  actually  finished 

•  walLtime:  total  time  elapsed  to  complete  the  Project 

•  totaLtime:  sum  of  all  Task  times  in  the  Project 

•  accuracy:  the  average  accuracy  of  all  of  the  Tasks  which  comprise  the  Project 

•  proj_jobs:  set  of  all  Jobs  involved  in  this  Project 

•  task_set:  set  of  all  Tasks  involved  in  this  Project 

3.4.2.II  Organization.  The  Organization  object  is  defined  as  a  set  of  zero  or  more 
Project  objects,  a  ToolSet ,  a  Workforce ,  and  a  ManningPlan.  The  attributes  of  the  Organization 
are: 

•  unit-effectiveness:  a  derived  metric  which  describes  the  Organization’s  overall  effectiveness. 

•  unit_efficiency:  a  derived  metric  which  describes  the  Organization’s  overall  efficiency. 

•  unit_readiness:  a  metric  which  describes  the  Organization’s  overall  readiness. 

3.4.3  Object  Model  Associations.  The  interrelationships  among  the  objects  are  depicted 
in  the  OMT  method  through  the  use  of  associations.  Each  association  may  or  may  not  have 
attached  to  it  a  set  of  attributes.  The  values  of  the  attributes  of  all  associations  are  derived  from 
the  attributes  of  their  associated  objects.  In  the  current  model,  the  following  associations  between 
object  classes  are  identified.  These  associations  have  their  multiplicity  defined  using  the  symbology 

in  Table  1.  Each  individual  association  is  described  in  detail  in  the  following  sections. 

•  using:  Tool  -++  Worker 

•  qualified-on:  Tool  <-»  Worker 

•  assigned :  Job  -+»  Tool 

•  supports:  (Tool  x  Job)  — »  SupportsAttr 

•  assignment:  Job  -++  Worker 

•  qualified-for:  (Worker  x  Job)  — >  Qualified Attr 

•  occupy:  Position  >+->  Worker 

•  precedes:  Job  Job 
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3. 4 ’3.1  Using  Association.  The  using  association  links  a  Tool  to  a  Worker  and 
shows  that  the  Worker  is  currently  using  the  Tool  in  the  accomplishment  of  a  Job .  The  association 
is  a  one-to-many  relationship  from  Worker  to  Tool  This  association  has  no  attributes.  This 
association  is  useful  if  a  user  wishes  to  know  the  Tools  a  Worker  is  currently  using  or  the  Worker 
who  is  currently  using  a  certain  Tool. 

34.3.2  Qualified-On  Association.  The  qualifiedLon  association  links  a  Tool  to  a 
Worker  and  shows  what  Tools  a  Worker  is  qualified  to  use  in  the  accomplishment  of  a  Job.  The 
association  is  a  many-to-many  relationship  from  Tool  to  Worker.  This  association  has  no  attributes. 
This  association  is  useful  if  a  user  wishes  to  know  which  Tools  a  particular  Worker  is  qualified  to 
use  or  which  Workers  are  qualified  to  use  a  certain  Tool.  For  a  Worker- Tool  pair  to  be  in  the  set 
of  qualifiedLon  associations,  the  afsc  of  the  Worker  must  be  a  member  of  the  afsc_set  of  the  Tool. 

34.3.3  Assigned  Association.  The  assigned  association  links  a  Tool  to  a  Job  and 
shows  the  Tool  that  has  been  selected  to  aid  in  the  accomplishment  of  a  Job.  The  assigned  associ¬ 
ation  is  a  one-to-many  relationship  from  Tool  to  Job.  This  association  is  useful  if  a  user  wishes  to 
know  the  Tool  that  has  been  assigned  to  assist  in  the  accomplishment  of  a  particular  Job ,  or  the 
Jobs  to  which  a  particular  Tool  has  been  assigned. 

34-34  Supports  Association.  The  supports  association  links  a  Tool  to  a  Job  and 
shows  that  a  Tool  may  support  the  accomplishment  of  a  Job.  This  association  is  a  many-to-many 
relationship  between  Tool  and  Job  with  two  attributes,  time  and  percentage.  This  association  has 
the  following  attributes: 

•  time:  indicates  the  amount  of  time  saved  when  a  qualified  Worker  uses  the  Tool  to  accomplish 
the  Job 
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•  percentage:  indicates  the  increased  accuracy  amount  when  a  qualified  Worker  uses  the  Tool 
to  accomplish  the  Job.  Tool  percentage  values  range  from  0,  meaning  the  Tool  provides  no 
support  for  the  Job ,  to  100,  meaning  the  Tool  can  accomplish  the  Job  in  an  automated  mode 
without  the  need  for  a  Worker  assignment. 

The  supports  association  describes  how  well  a  Tool  supports  a  particular  Worker  in  accom¬ 
plishing  a  Job.  The  link  attributes  percentage  and  time  are  used  in  the  following  manner.  If  a  Job 
is  to  write  a  book,  a  Worker  might  use  a  pen,  typewriter,  or  word  processor.  All  of  the  Tools  might 
be  optional;  however,  the  pen  may  have  a  supports  level  percentage  of  10  while  the  typewriter 
might  have  a  supports  level  percentage  of  40  and  the  word  processor  might  have  a  supports  level 
percentage  of  75.  If  this  Tool  is  assigned  to  be  used  on  a  Job,  then  the  Job’s  time  and  accuracy 
attributes  are  adjusted  accordingly  as  described  in  Section  3. 4. 2. 8. 

34.3.5  Assignment  Association.  The  assignment  association  links  a  Job  to  a  Worker 
and  shows  that  a  Job  to  Worker  assignment  has  been  made.  The  assignment  association  is  a  one-to- 
many  relationship  from  Worker  to  Job.  This  association  is  useful  if  a  user  wishes  to  find  the  Worker 
assigned  to  a  given  Job,  as  well  as  to  find  the  Jobs  assigned  to  a  given  Worker.  The  assignment 
association  shows  that  Worker  objects  can  be  part  of  multiple  Worker- Job  assignments.  Although 
there  are  no  attributes  attached  to  the  assignment  association,  the  attributes  of  the  Worker  and 
the  Job  do  impact  the  time  and  accuracy  attributes  of  the  Job  object.  These  attributes  (time  and 
accuracy)  must  be  calculated  based  on  each  particular  Worker- Job  and/or  Tool- Job  assignment 
pairing(s).  These  attributes  indicate  the  following  about  a  Job  object: 

1.  time  -  A  calculation  of  how  long  it  should  take  to  complete  a  Job. 

2.  accuracy  -  A  calculation  of  how  error- free  the  output(s)  of  a  Job  should  be. 

In  the  original  object  model,  the  time  and  accuracy  attributes  had  been  attached  to  the  actual 
assignment  association  between  a  Worker  and  a  Job.  This  situation  did  not  allow  a  Job  to  have 
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a  time  and  accuracy  measure  without  the  assignment  of  a  Worker.  To  prevent  this  situation,  the 
attributes  were  moved  to  the  Job ,  thereby  allowing  a  Job  to  be  accomplished  without  the  assignment 
of  a  Worker.  This  was  necessary  to  allow  the  ability  of  an  automated  Tool  object  to  be  assigned 
to  accomplish  a  Job  and  still  have  the  needed  time  and  accuracy  measures  for  the  Job. 

It  is  necessary  to  calculate  the  actual  time  required  to  perform  the  Job  with  the  assignment 
of  a  particular  Worker.  The  average  time  to  complete  a  Job ,  the  time  it  would  take  the  average 
qualified  worker  to  complete  the  Jo6,  is  available  as  an  attribute  of  Jo6,  as  well  as  the  best  and 
worst  time  to  complete  a  Job.  Also  available  is  the  automated  time,  the  time  it  would  take  to 
accomplish  the  Job  if  it  is  accomplished  by  an  automated  Tool.  The  actual  time  and  accuracy  are 
calculated  based  on  the  following  criteria.  If  the  assigned  Worker  does  not  possess  an  afsc  which 
is  in  the  Job’s  afsc_set  then  the  assignment  is  not  possible.  If  the  Worker’s  skill  level  is  lower  than 
the  skill  level  desired  by  the  Job ,  the  actual  time  will  be  greater  than  the  expected  time.  If  the 
person  selected  has  an  afsc  in  the  Job  s  afsc_set  and  a  higher  skill  level  than  the  Job  desires,  the 
Job’s  actual  time  will  be  less  than  the  expected  time.  If  a  Tool  is  assigned  to  assist  in  the  Job,  the 
Job’s  actual  time  may  be  less  than  the  expected  time,  based  on  the  time  savings  the  Tool  provides. 
The  actual  calculations  for  determining  the  time  to  perform  the  Job  should  be  defined  based  on 
domain  specific  expected  time  values  from  research  in  this  area,  as  well  as  information  furnished 
by  domain  experts. 

The  accuracy  of  the  Job  as  performed  by  the  selected  Worker  is  also  calculated.  Accuracy  is  a 
measure  of  the  correctness  of  the  output  of  a  Job.  Calculating  the  accuracy  is  similar  to  calculating 
the  time  of  a  Job.  If  the  person  assigned  to  a  task  is  fully  qualified,  that  is,  the  person  has  an  afsc 
which  is  in  the  Job’s  afsc_set,  the  accuracy  will  be  greater  than  or  equal  to  the  expected  accuracy. 
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However,  if  the  Worker’s  afsc  is  not  in  the  Job’s  afsc_set,  once  again  the  assignment  is  not  possible. 
The  skill  level  of  the  Worker  again  affects  the  accuracy  in  the  same  manner  as  it  affects  time.  The 
use  of  Tools  to  accomplish  a  Job  can  also  increase  the  accuracy  figure.  Each  Tool  which  supports  a 
Job  has  associated  with  it  a  time  attribute  which  indicates  the  amount  of  time  a  qualified  Worker 
will  expect  to  save  by  using  the  Tool  to  accomplish  the  Job  as  well  as  the  increase  in  accuracy  a 
qualified  Worker  will  expect  by  using  the  Tool  to  accomplish  the  Job. 


34.3.6  Qualified-For  Association.  The  qualifie<L.for  association  links  a  Worker  to 
a  Job  and  indicates  that  a  particular  Worker  has  the  attributes  necessary  to  accomplish  a  certain 
Job.  This  association  is  a  many-to-many  relationship  between  Worker  and  Job  with  two  attributes 

named  expect_accuracy  and  expect_time.  The  attributes  are  defined  as  follows: 

•  expect_accuracy:  indicates  the  expected  accuracy  of  a  Job  to  Worker  assignment  in  the 
accomplishment  of  a  Job.  This  value  is  to  be  obtained  from  a  data  base  of  domain  specific 
information  concerning  Job  accomplishment  by  Workers. 

•  expect_time:  indicates  the  expected  time  of  a  Job  to  Worker  assignment  in  the  accomplish¬ 
ment  of  a  Job.  This  value  is  to  be  obtained  from  a  data  base  of  domain  specific  information 
concerning  Job  accomplishment  by  Workers. 


34.3.7  Occupy  Association.  The  occupy  association  is  a  one-to-one  relationship  be¬ 
tween  Worker  objects  and  Position  Objects.  This  association  is  needed  to  compute  the  Workforce 
object’s  force_readiness  attribute.  By  comparing  each  Position  in  the  overall  Organization’s  Man- 
ningPlan  object  to  the  Worker  object  that  is  actually  occupying  that  Position,  a  force  readiness 
factor  can  be  calculated.  The  force_readiness  is  a  measure  of  the  percentage  of  the  Positions  in  the 
Organization  which  are  filled  by  a  qualified  Worker.  This  is  determined  by  comparing  the  afsc  and 
the  skill  level  of  the  Worker  to  the  Position  the  Worker  occupies. 
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34*3.8  Precedes  Association.  The  precedes  association  is  a  many-to-many  relation¬ 
ship  between  Job  objects.  The  precedes  association  links  Job  objects  to  other  Job  objects  and 
shows  which  Jobs  must  be  accomplished  before  a  particular  Job  can  begin.  This  association  has 
no  attributes.  This  association  is  useful  if  a  user  wishes  to  determine  the  predecessors  of  a  given 
Job  or  the  Jobs  which  it  precedes.  This  association  is  dependent  on  (derived  from)  the  inputs  and 
outputs  of  the  Job  objects. 

344  Dynamic  Model  The  previous  research  effort  did  not  include  a  dynamic  model. 
However,  the  new  model  with  its  added  objects  and  associations  does  need  a  dynamic  model  to 
describe  the  state,  events,  and  actions  of  the  lowest  level  objects  in  the  model.  These  objects 
include  the  J06,  the  Too/,  and  the  Worker.  These  objects  are  the  only  ones  whose  states  must  be 
described  to  fully  define  the  dynamic  behavior  of  the  system,  and  are  described  in  the  following 
sections. 


3.4.4.I  Job  Dynamic  Model  In  the  dynamic  model,  the  Job  object  must  be  able  to 
transition  between  its  allowable  states.  These  transitions  occur  based  on  certain  guard  conditions 
and  system  events.  Figure  9  displays  the  dynamic  model  for  the  Job  object. 


[predecessors  done]  [System_Time=End_Time]/JobFmished 


StartJob(job) 


Figure  9.  Job  Object  Dynamic  Model 
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344-2  Tool  Dynamic  Model.  The  dynamic  model  for  the  Tool  object  is  very 
simple  since  it  involves  only  two  possible  states  and  responds  to  only  two  system  events.  A  Tool 
transitions  from  the  available  status  to  the  in  use  status  upon  receipt  of  the  StartTool  event  and 
back  to  available  upon  receipt  of  the  StopTool  event.  This  is  seen  in  Figure  10. 


StartTool 


StopTool 

Figure  10.  Tool  Object  Dynamic  Model 


34.4.3  Worker  Dynamic  Model.  The  Worker  object  dynamic  model  is  the  most 
complex  of  the  three.  The  events  and  guard  conditions  it  responds  to  and  the  actions  it  initiates 
are  shown  in  the  illustration  in  Figure  11. 

3.4.44  Event  Flow.  A  part  of  the  dynamic  model  which  is  used  to  describe  event 
communication  between  objects  in  the  dynamic  model  is  the  event  flow  diagram  (EFD).  In  the  EFD 
for  this  model  there  is  a  scheduler  which  is  used  to  issue  Start  Job  and  receive  JobDone  events.  It  was 
decided  to  evaluate  whether  it  was  necessary  to  have  this  scheduler  or  if  the  model  could  function 
properly  without  it.  The  dynamic  model  was  modified  to  explore  the  possibility  of  eliminating 
the  scheduler.  This  resulted  in  some  conditions  which  require  objects  to  know  information  about 
other  objects.  It  was  decided  that  this  condition  should  be  avoided  if  at  all  possible.  Therefore, 
the  scheduler  remains  part  of  the  EFD  and  the  system  as  depicted  in  Figure  12.  This  provides  for 
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S tartJ ob (job) [ tool_needed]/S tartT ool ,  calc_accuracy,  calc_time 


StartJob(job) 
[no_tool_needed]/ 
calc_accuracy,  calc_time 


better  information  hiding.  The  including  of  a  scheduler  follows  the  Job  Shop  approach  as  discussed 


in  2.6.3. 


Figure  12.  System  Event  Flow  Diagram 


3.4.5  Functional  Model.  Development  of  the  functional  model  is  necessary  to  capture 
the  functional  aspects  of  the  domain  model.  The  actions  which  must  occur  have  to  be  described. 
This  area  is  focused  on  the  J06,  Worker ,  and  Tool  objects  and  the  attribute  values  which  must  be 
calculated  for  them  and  their  associations.  The  functional  model  used  for  this  research  is  based  on 
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the  one  supplied  by  previous  research  (11).  It  was  not  modified,  but  only  portions  of  it  are  actually 
included  in  the  Z  and  Refine  models. 

3.5  AF  Wing  Z  Model 

3.5.1  Z  Base  Sets.  In  the  process  of  implementing  Z  schemas  it  is  necessary  to  define 
several  basic  sets  for  use  within  the  individual  object  and  association  definitions.  These  sets  are 
basically  type  definitions  for  domain  specific  types  of  data  or  information  not  already  available 

through  Z.  The  additional  types  are: 

•  JOB-STATUS:  the  set  of  all  job  status  types 

•  DATA:  the  set  of  all  input  and  output  data  types 

•  AFSCS:  the  set  of  all  AFSCS 

The  JOB-STATUS  set  is  defined  as  {waiting,  ready,  in_process,  or  finished}  and  is  used  to  indicate 
not  only  the  status  of  a  Job,  but  also  the  status  of  Tasks  and  Projects.  This  type  of  information 
regarding  the  status  of  Jobs,  Tasks,  and  Projects  is  fairly  common  and  could  be  used  in  most 
domains.  The  DATA  type  set  used  will  be  more  domain  specific. 

The  data  type  set  used  for  this  research  was  generic  numbered  input  and  output  symbols  and 
is  used  for  the  input  and  output  data  for  Jobs  and  Tasks.  The  level  of  domain  knowledge  required 
to  fully  define  the  exact  inputs  and  outputs  for  each  Job  was  not  readily  available  but  was  not 
really  necessary  to  achieve  the  goals  of  this  research. 

The  AFSCS  set  is  used  to  hold  all  of  the  Air  Force  Specialty  Codes  relevant  to  the  organization 
being  modeled.  They  are  used  for  the  definition  of  the  afsc_set  attribute  of  the  Tool  objects  and 
Job  objects  as  well  as  for  the  afsc  attributes  of  the  Position  objects  and  Worker  objects.  These 
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three  base  sets  were  all  that  were  required  for  the  AF  organization  domain.  This  area  will  need  to 
be  examined  for  each  particular  domain  during  the  model  development  process. 


3.5.2  Worker  Object.  The  Worker  object  is  defined  by  the  following  Z  static  schema: 


_ W orker _ 

name  :  seqCHAR 
afsc  :  AFSCS 
skill-level  :  Af 
availability  :  BOOLEAN 
experience  :  A f 
education  :  Af 
aptitude  :  Af 

skill-level  >  1 
skill— level  <  9 
experience  >  0 
experience  <  30 
education  >  0 
education  <  18 
aptitude  >  0 
aptitude  <100 


3.5.3  Workforce  Object.  The  force_readiness  attribute  of  the  Workforce  is  defined  as  all 
of  the  correctly  occupied  Positions  in  the  Organization.  The  correctly  occupied  P ositions  are  the 
members  of  the  occupy  association  in  which  the  Worker’s  afsc  is  equal  to  the  Position’s  afsc  and 
the  Worker’s  skill  level  is  greater  than  or  equal  to  the  Position’s  skill  level.  The  Workforce  object 
is  defined  by  the  following  Z  static  schema: 
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_ Workforce - - - - - - - — 

worker  set  :  P  Worker 
force^readiness  :  R 

force-readiness  >  0 
force-readiness  <  100 
force-readiness  = 

#{^(^3^)  :  Occupy  p.af  sc  =  w. a  f  sc  Aw. skill-level  >  p.skill-level}/ (Work  force) 


3.5.3. 1  Tool  Object.  The  Too/  object  is  defined  by  the  following  Z  static  schema: 


_ Tool - 

name  :  seq  CHAR 
status  :  symbol 
a  f  sc— set  :  P  AFSCS 
skill-level  :  A f 
availability  :  BOOLEAN 

skill-level  >  1 
skill-level  <  9 


3.5.4  ToolSet  Object.  The  tooLxeadiness  attribute  of  the  ToolSet  is  defined  as  the  number 
of  Tool  objects  in  the  Organization's  ToolSet  with  a  status  equal  to  go  divided  by  the  number  of 
Tool  object  in  the  ToolSet.  The  ToolSet  object  is  defined  by  the  following  Z  static  schema: 


_ ToolSet — - - - 

toolset  :  P  Tool 
tool-readiness  :R 

tool -readiness  >  0 
tool— readiness  <  100 

tool -readiness  =  jf{t  :  Tool  •  t  G  toolset  A  t. status  =  ‘GO} /ffc (tool set) 


3.5.5  Position  Object. 


The  Position  object  is  defined  by  the  following  Z  static  schema: 
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Position _ 

number  :  A f 
afsc  :  AFSCS 
skill-level  :  M 

skill-level  >  1 
skill-level  <  9 


3.5.6  ManningPlan  Object.  The  ManningPlan  object  is  defined  by  the  following  Z  static 
schema: 


3.5.7  Job  Object.  The  Job  object  is  defined  by  the  following  Z  static  schema: 
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Job _ _ _ : - 

name  :  seq  CHAR 
priority  :  Af 
a  f  sc-set  :  P  AFSCS 
skillJlevel  :  Af 
status  :  JOB-STATUS 
complexity  :  Af 
inputs  :  P  DATA 
outputs  :  P  DATA 
average-time  :  Af 
best— time  :  A f 
worst-time  :  Af 
automated-time  :  Af 
average— accuracy  :  A/" 
best-accuracy  :  Af 
worst-accuracy  :  A/" 
percent— complete  :  A/" 
start-time  :  A/* 
end-time  :  Af 
accuracy  :  Af 
time  :  Af 

priority  >  0 

priority  <  100 

skill-level  >  1 

skill-level  <  9 

complexity  >  0 

complexity  <100 

percent— complete  >  0 

percent-complete  <100 

end-time  >  start-time 

time  —  start-time  —  end-time 

automated-time  <  best-time  <  average-time  <  worst-time 
[percent— complete  =  1.0)  — ►  ( status  =  finished ) 

(percent-complete  >  0.0  A  percent-complete  <  1.0)  — ►  ( status  =  in-process ) 
inputs  fl  outputs  —  {  } 

(£irae  >  automated-time) 

(time  <  worst-time) 


In  the  Z  static  schema  for  the  Job  object,  part  of  the  behavior  of  the  Job  is  based  on  the 
status  and  percent_complete  attributes.  When  a  percent-complete  is  equal  to  1.0  this  implies 
that  the  Job’s  status  must  be  equal  to  finished .  Furthermore,  if  the  percent— complete  attribute  of  a 
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Job  is  less  than  1.0  and  greater  than  0.0,  then  the  Job’s  status  must  be  in-process ,  These  conditions 
are  necessary  for  the  behavior  of  the  Job  to  be  consistent. 

To  prevent  a  deadlock  situation  where  a  Job  needs  as  one  of  its  inputs  a  data  item  that  it 

supplies  as  one  of  its  outputs,  the  input  and  output  data  sets  must  not  have  a  member  in  common. 

This  is  prevented  with  the  following  predicate. 
inputs  fl  outputs  =  {  } 

In  the  model,  the  Job  attributes  average-time ,  best-time ,  worst-time ,  and  automated-time 
are  related  to  each  other.  Obviously,  the  worst-time  should  be  longer  than,  or  at  best  the  same 
as,  the  average— time.  The  average— time  has  a  similar  relationship  with  the  best— time ,  and  the 
automated-time  will  undoubtably  always  be  the  shortest.  The  time  attribute  is  the  actual  time 
needed  to  complete  the  Job  and  must  always  be  at  least  as  much  as  the  automated-time  and  never 
greater  than  the  worst-time.  These  relationships  are  captured  in  the  following  predicates. 
automated-time  <  best-time  <  average-time  <  worst-time 
( time  >  automated-time ) 

(time  <  wor st-time) 

3.5.8  Task  Object.  The  Task  object  is  defined  by  the  following  Z  static  schema: 
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Task _ 

name  :  seq  CHAR 
priority  :  A f 
status  :  JOB-STATUS 
inputs  :  DATA 
outputs  :  DATA 
times  0-f  ar  :  J\f 
percent— complete  :  R 
number sf -jobs  :  A f 
jobs -complete  :  J\f 
start— time  :  A/* 
end-time  :  A/* 
wall-time  :  Af 
total-time  :  i? 
accuracy  :  AT 
jobset  :  P  JOBS 


priority  >  0 
priority  <100 
percent-complete  >  0 
percent— complete  <  100 
start-time  —  min 

V  j£  job— set 

end-time  —  max  {j  .end-time) 

V  j'E  job— set 

total— time  =  j.time 

V  job— set 


wall-time  —  start-time  —  end-time 
wall-time  <  total-time 

jobssomplete  —  #{j  :  job  \  j  G  jobset  A  j. status  =  finished} 

number -of -jobs  =  {jobset) 

jobs— complete  <  number— of —jobs 

(3  j  :  job  •  j  G  jobset  A  j. status  =  inprocess)  — > 
timeso-f  ar  =  j. start-time  +  j.time  *  j  .per  cent-complete 

percent-complete  =  ^  j.time/  ^  j.time 

V  j  € job— set*  j.  status  =  finished  V  jEjobset 
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_ Task(C  ontinued) _ _ _ _ _ — - — 

V j  •  j  G  jobset  A  j. status  =  finished  — >  status  =  finished 

Vj  G  job— set  •  (j. status  —  waiting )  — ►  status  —  ( waiting ) 

V  j  G  jobset  •  (j .status  =  ready)  — ►  status  =  (ready) 

3  j  £  jobset  •  j. status  =  in-process  — >  status  =  in-process 

(jobssomplete  =  number -of -jobs)  — >  (percent-complete  =  100)  A  (status  =  finished) 

{Vji  G  jobset  •  ji.mjmis  0  [{V  j2  :  jobset  •  j2. inputs}  fl  {Vj3  :  jobset  •  j3. outputs}]}  — ► 
j.inputs  G  inputs 

{Vji  G  jobset  •  j1. outputs  £  [{V j2  •  jobset  •  j2. inputs}  fl  {V j3  :  jobset  •  j^. outputs}]}  — 
j.outputs  G  outputs 

inputs  fl  outputs  =  {  } 

accuracy  =  ^  j.  accuracy /if  (jobset) 

V  j£  job— set 


In  the  TasA:  object,  the  start  and  end  times  of  the  Task  are  dependent  upon  the  start  and  end 
times  of  the  Jo&s  in  the  job_set  of  the  Task.  This  is  captured  in  the  following  predicates. 

start— time  =  min  (j.  start— time) 

V  j£  job— set 

end-time  =  max  (j. end-time) 

V  jE  job— set 

The  total  time  spent  on  the  Task  is  simply  the  sum  of  the  times  of  all  the  Jots  in  the  jobset 
and  the  wall-time  of  the  Task  is  simply  the  end-time  minus  the  start-time  of  the  Task.  Since  the 
wall— time  takes  into  account  the  concurrency  of  Jo&s  and  the  total— time  does  not,  the  wall— time 
can  never  be  greater  than  the  total-time.  This  behavior  is  captured  in  the  following  predicates. 
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total-time  =  ^  j.time 

V  job— set 

wall-time  =  start-time  —  end-time 
wall-time  <  total-time 


To  express  the  timeso-far  attribute  of  the  Task  at  any  point  in  time  requires  knowing  the 

maximum  end— time  of  all  the  Jobs  in  the  job— set  which  have  been  completed.  Also  required  is  the 

Job  which  has  consumed  the  most  time  and  is  currently  in  the  in-process  status.  These  requirements 

are  expressed  in  the  following  predicate. 

(3  j  :  job  E  jobset  A  j. status  =  inprocess )  — ► 

timeso-far  =  j. start-time  4-  j.time  *  j. percent-complete 


The  percent-complete  attribute  of  the  Task  can  be  approached  in  two  manners.  First,  it  could 
be  based  solely  on  the  percentage  of  Jobs  in  the  jobset  which  have  been  completed.  However, 
this  does  not  take  into  account  the  event  that  the  last  Job ,  or  any  Job(s),  could  be  extremely 
time  intensive.  The  second  approach  is  to  base  the  percent— complete  on  the  amount  of  time  of 
completed  Jobs  versus  the  total  time  to  complete  all  Jobs.  The  second  approach  was  decided  to  be 
more  realistic  and  chosen  for  implementation.  The  predicates  for  both  approaches  respectively  are 


as  follows. 


nprrpmt  rnmnlete  ~  status  =  finished } 

perceni-compteie  —  #(jobset) 

percent-complete  =  E  j.time/  j-time 

V  job—  set  *j.  status  =  finished  V  j€  job— set 


The  status  of  the  Task  is  dependent  on  the  status  of  the  Jobs  which  make  up  the  Task’s 
job__set.  In  order  for  the  Task  to  be  finished,  all  of  the  members  of  the  job_set  must  be  finished. 
Also,  if  all  of  the  Jobs  in  the  job_set  are  in  waiting  status  or  ready  status  then  the  Task  must 
also  be  in  the  same  respective  status.  Finally,  once  all  of  the  Jobs  in  the  job_set  are  complete, 
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jobs_complete  will  be  equal  to  number_of_jobs.  This  implies  that  the  Task  must  be  finished  and 
the  percent_complete  will  be  equal  to  1.0.  These  behaviors  are  captured  in  the  following  predicates. 

3j  e  job-set  •  j. status  7^  finished  — *•  status  ^  finished 

V  j  €  jobset  •  (j. status  =  waiting )  — +  status  —  ( waiting ) 

Vj  G  jobset  •  (j. status  =  ready)  — >  status  —  (ready) 

3j  G  jobset  •  j. status  =  in-process  —>  status  =  in-process 

(jobs— complete  =  number— of —jobs)  — *  (percent— complete  =  100)  A  (status  =  finished) 

To  derive  the  inputs  to  a  Task  it  is  necessary  to  specify  the  inputs  to  the  Jo bs  in  the  job_set 
which  are  not  outputs  from  another  Job  within  the  job_set.  The  intersection  between  the  inputs 
and  outputs  of  the  Jobs  in  the  jobset  are  internal  to  the  Task.  Only  the  inputs  and  outputs  not  in 
the  intersection  can  be  inputs  and  outputs  which  cross  the  boundaries  of  the  Task  and  are  therefore 
members  of  the  Task’s  inputs  and  outputs  sets  respectively.  The  following  predicates  specify  this 
behavior. 

{V  ji  G  jobset  •  ji .inputs  &  [{V  j2  :  jobset  •  j2. inputs}  fl  {V  j3  :  jobset  •  j3.outputs}}}  — > 
j.inputs  G  inputs 

{Vji  G  jobset  •  ji  .outputs  £  [{Vj2  :  jobset  •  j2 -inputs]  fl  {V  j3  :  jobset  •  j3. outputs}]}  — » 
j. outputs  G  outputs 

3.5.9  Project  Object.  The  Project  object  is  defined  by  the  following  Z  static  schema: 
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Proj  ect - 

name  :  seq  CHAR 
priority  :  A f 
status  :  JOB-STATUS 
timeso-f  ar  :  R 
number -of -tasks  :  J\f 
tasks-complete  :  A f 
percent-complete  :  R 
number -of -jobs  :  Af 
jobs -complete  :  Af 
start-time  :  Af 
end-time  :  Af 
wall-time  :  Af 
total-time  :  i? 
accuracy  :  A/" 
taskset  :  P  TASKS 
job-set  :  P  JOBS 


priority  >  0 
priority  <  100 
percent— complete  >  0 
percent— complete  <  100 
jobset  =  [J  t.jobset 

V  t^taskset 


Vj  :  Job9  j  6  ran(precedes)  => 

(V(Jk,  j)  :  Precedes  •  (fc,  j)  €  precedes  A  j. start-time  > 
start-time  —  min  (£.star£_£irae) 

V  tGtask—set 

end-time  =  max  ( t.  end-time ) 

V  tEtask—set 

total-time  —  ^  t.time 

V  ttztaskset 

wall-time  =  start-time  —  end-time 
wall-time  <  total-time 

tasks-complete  =  :  taskset  •  t. status  =  /misled} 

number -of -tasks  =  #(tasfc_set) 
tasks-complete  <  number -of -tasks 


max  (k.  end-time)) 
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_ Project(Continued) - - - 

times  o—f  ar  =  max  ( t. end— time) -\- 

V  t£taskset»t.  status  =  finished 

max  ( t.time  *  t. percent-complete) 

V  tEtaskset^t.  status  =  in— process 

(3  j  :  job  •  jinj obset  A  j. status  =  in  —  process)  — ► 
times o—f  ar  =  j. start-time  +  j.time  *  j, percent-complete 

percent— complete  =  E  t.time/  t.time 

V  Uztask—set*t.  status  =  finished  V  tEtaskset 


As  can  be  seen  from  the  predicates,  the  attributes  of  the  Project  object  are  very  similar  to  the 
attributes  of  the  Tas&  object.  However,  in  the  Project  attribute  section  there  is  a  redundant 
job_set.  This  is  the  set  of  all  Jo 6s  which  are  in  the  Tasks  within  the  Project’s  task-set.  Since  it  was 
necessary  to  access  some  of  the  attributes  of  individual  Jobs  in  deriving  several  of  the  attributes  of 
the  Project ,  it  was  necessary  to  have  the  jobset  declared  and  derived  at  the  Project  level. 

3.5.10  Organization  Object.  The  Organization  object  is  defined  by  the  following  Z  static 
schema: 
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_ Organization _ 

Assigned 

Using 

Qualified-On 

Assigned 

Assignment 

Qualified-For 

Supports 

Occupy 

Precedes 

toolset  :  P  Tools 

workforce  :  P  Workers 

projectset  :  P  Projects 

manningplan  :  P  Positions 

unit-ef  f  iciency  :  Af 

unit-e f  f  ectiveness  :  M 

unit-readiness  :  R 


unit-e f  f  iciency  >  0 
unit-ef  f iciency  <  100 
unit— ef  f  ectiveness  >  0 
unit-e f  f  ectiveness  <  100 
unit— readiness  >  0.0 
unit-readiness  <1.0 

[(V(wi,ii)  •  (tUl.ji)  €  assignment)  — *  ((u>i,  ji)  G  qualified-/ or)] 

[( V(i,  j )  •  (i,  j)  G  assigned)  ->  (( t,j )  G  supports) 

[(V(t u,t)  •  (u;,i)  G  using)  — *•  (( w,t )  G  qualified-on )] 

[(V(u>,i)  •  (to,  t)  G  using)  — >  (3  j  •  (( w,j )  G  assignment)  A  (( t,j )  G  assigned)] 

[(V(iOi,  jx)  •  (tOi,ji)  G  assignment)  A  (Vi  •  (t,  ji)  G  supports)  A  (( t,j1 )  £  assigned )]  — ► 
[((t, 0  using-)  A  ((u>i,  ji)  G  quali f  ied-f  or) A 

(ji.accuracy  =  ((quali  f  ied-f  or  (wx,  ji). expected-accuracy)  *  normal-distribution))] 

•  (t\,Wi)  G  using)  A  (3  •  (ti,ji)  G  assigned)  A  (tWi,Ji)  G  assignment )]  — > 

ji.accuracy  =  qualified-/ or(wi,ji).expect-accuracy  +  supports(ti,ji). percentage 

(t,j)  G  supports  — ►  supports(t,  j) .percentage  <  100 
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_ Organization(continued) - - - 

(w,j)  G  qualified-f  or  — >  qualifiedf  or  (w,j). expect-accuracy  <  100 

(-1  3tXiwx  •  (tijWi)  G  using  A  (wx,jx)  G  assignment ))  — ► 
j  i  .time  =  qualified-f  or(tx,wx).expect-time  *  nor  maldistribution 

[(3 ti, te;i  •  (ti,iwi)  G  using )  A  (3 jx  •  G  a55^nment)A 

(ti?i7i)  G  supports  A  G  assigned)]  — > 

ji.time  =  ( qualified-f  or{wx,  jx).expect-time  *  normal-distribution)  —  supports^,  jx).time 
V(u>u  Ji)  ^  qualified-f  or  •  (wx.afsc  G  jx.af  scset) A 

(w1. skill-level  >  jx.  skill-level)  — >  qualified-f  or  (wx,  jx).expect-time  =  ji- best-time 
V(wu  ji)  G  qualified-f  or  •  ( Wi.afsc  G  ji-af  scset)  A 

(wx. skill-level  =  j1. skill-level)  — ►  qualified-f  or  {wujx).expect-time  =  jx.  aver  age-time 

V(io,j)  •  (w,  j)  G  qualified-f  or  — ►  qualified-f  or  (w,j).expect-time  >  0 

V(iu,  j)  •  G  qualified-f  or  — >  qualified-f  or  (w,  j). expect-accuracy  >  0 

V(ty,  j)  •  (w,  j)  G  qualified-f  or  —>  qualified-f  or  (wj). expect-accuracy  <  100 

V(t,  j)  •  (t,j)  G  supports  — ►  support s(t,j). time  >  0 

V(wi,  ji)  •  (tui,  ji)  G  qualified-f  or  A  ( wx.af  sc  G  ji-af  scset)A 

(wx  .skill-level  <  ji. skill-level)  — >  qualified-f  or  (wu  jx).expect-time  —  jx. worst-time 
V(tui,  ji)  •  (iui,  ji)  G  qualified-f  or  A  (wx.af  sc  E  jx.af  sc-set)  A 

(wx. skill-level  >  ji.s&iiZ-JeveZ)  —►  qualified-f  or(wx,jx).expect-accuracy  =  jx. best-time 
V(wujx)  •  G  qualified-f  or  A  ( wx.afsc  G  Ji  A 

(wx. skill-level  =  jx.  skill -lev  el)  — >  qualified-f  or. expect-accuracy  =  jx.  aver  age-time 
V(wuji)  •  (twi,ji)  G  qualified-f  or  A  ( wi.afsc  G  jx.af  SC-Set)  A 

(wx. skill-level  <  jx. skill-level)  — >  qualified-f  or  (wx,jx).  expect-accuracy  =  jx. worst-accuracy 
V(wuji)  •  (^1,  ji)  €  qualified-f  or  A  (wx.afsc  G  jx.af  sc-set)  A 

(wx. skill-level  ~  jx.  skill-lev  el)  — >  qualified-f  or  (wx,jx). expect-accuracy  —  jx.  aver  age-accuracy 
V(wujx)  •  G  qualified-f  or  A  (wx.afsc  G  jx.af  sc-set)  A 

(wx.  skill-level  >  jx.  skill -lev  el)  —>  qualified-f  or  (wx,jx).  expect-accuracy  —  jx. best-accuracy 

V(wx,jx)  •  (wi,  ji)  G  qualified-f  or  A  ( wx.afsc  G  jx.af  sc-set)  A 
(wx. experience  >  10)  A  {jx. complexity  <  75)  —> 

qualif  ied- for  (wx,jx).  expect-accuracy  =  qualified-f  or  (wx,jx). expect-accuracy  +  20 
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_ Or  ganization{C  ontinued) - — — - 

V(wi,ji)  •  Oi,ii)  e  qualified^/ or  A  ( w1.afsc  G  j\.af  sc-set)  A 
(w1. education  >  12)  A  (ji- complexity  <  50)  — ► 

qualified-f  or  (wuji). expert-accuracy  =  qualified-f  or(w1,  j^.expect-accuracy  +  10 
tool  set. tool -readiness  =  #{Vt  •  t  G  toolset  A  tool. status  —  go} /^(toolset) 
workforce,  force-readiness  = 

u;)  •  (p,  it;)  G  occupy  A  (u;.a f  sc  —  p.af  sc )  A  (w. skill— level  >  p. skill— level)} / f^(manningplan) 
unit-readiness  =  toolset.tool-readiness  +  workforce,  force-readiness 


Most  of  the  predicates  for  the  Organization  deal  with  the  associations  of  the  model.  Some  of  the 
more  interesting  associations  are  discussed  in  the  following  sections. 

3.5.ii  Occupy  Association.  The  Occupy  association  is  defined  with  the  following  Z  static 
schema: 

Occupy - — - - - - — 

I  occupy  :  Worker  >-+*  Position 


3.5.12  Using  Association.  For  any  Worker- Tool  pair  to  be  a  member  of  the  using  asso¬ 
ciation,  there  is  the  implication  that  there  is  a  Job  such  that  it  is  in  an  assigned  association  pair 
and  that  the  Worker  is  qualified  on  the  Tool  and  that  particular  Tool  supports  the  Job  and  that 
the  Worker  has  been  assigned  to  the  Job  and  that  the  Worker  is  qualified  for  the  Job.  The  Using 
association  is  defined  with  the  following  Z  static  schema: 

_ U  sing _ _ _ _ _ 

using  :  Tool  Worker 

M(t,w)  G  using  — ►  [3  j  :  JOB  •  (£,  j)  G  assigned  A  (t,w)  G  qualified-on 
(t:j)  G  supports  A  (w:j)  G  assignment  A  (w,j)  G  quali f  ied-f  or] 
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3.5.13  Qualified-On  Association.  To  be  a  member  of  the  qualified-on  association,  the 
Worker’s  afsc  must  be  in  the  Tool’s  afsc  set  and  the  Worker’s  skill  level  must  be  greater  than  or 
equal  to  the  Tools  skill  level.  The  Qualified_On  association  is  defined  with  the  following  Z  static 
schema: 


Qualified-on _ _ _ _ _ 

qualified— on  :  Tool  Worker 

\/(t,w)  G  qualified-on  — ►  ( w.afsc  G  t.afscset)  A  (w.  skill -lev  el  >  t.  skill -lev  el) 


3.5.14  Assigned  Association.  The  conditions  for  being  a  member  of  the  assigned  associa¬ 
tion  are  very  similar  to  the  using  association.  The  Assigned  association  is  defined  with  the  following 
Z  static  schema: 


_ Assigned - - - - — 

assigned  :  Job  -+->  Tool 

V(t,  j)  G  assigned  — >  [3w  •  (£,  w)  G  using  A 
(t,w)  G  qualified-on  A  (xu,  j)  G  quali  f  ied-f  or  A 
(w:j)  G  assignment  A  (t,j)  G  supports } 


3.5.15  Supports  Association.  The  Supports  association  is  defined  with  the  following  Z 
static  schema: 


_ Supports  Attr _ 

time  :  A f 
percentage  :  A f 

time  >  0 
percentage  <  100 
percentage  >  0 
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_ Supports - 

supports  :  ( Tool  x  Job)  — ►  Supports Attr 

V(t,  j)  E  dom(s'upports)  — ►  t.afsc  E  j. a  f  sc-set 


3.5.16  QualifiecLFor  Association.  The  Qualified_For  association  is  defined  with  the 
following  Z  static  schema: 


Qualif  ied— For  Attr _ 

expect-time  :  Af 
expect-accuracy  :  J\f 

expect-time  >  0 
expects accuracy  <100 
expect— accuracy  >  0 


_ Qualified— For - 

quali f  ied-f  or  :  (hForfcer  x  Jo6)  — ►  Qualif  ied-F  or  Attr 

V(ty,j)  E  dom  (qualif  ied-f  or)  — ►  w.afsc  E  j. a  f  sc-set 


3.5.17  Assignment  Association.  The  assignment  association  is  defined  with  the  following 
Z  static  schema: 

_ Assignment _ _ _ — - - - 

assignment  :  Job  -++  ITorfcer 

V(j,  iu)  E  assignment  — >  w.afsc  E  j.afscset  A  (j, «;)  E  qualif  ied-f  or 


3.5.18  Precedes  Association.  All  Job  pairs  in  the  precedes  association  must  adhere  to  the 
following  conditions:  the  outputs  from  the  first  member  of  the  pair  must  intersect  with  the  inputs 
of  the  second  member  and  the  end  time  of  the  first  must  be  less  than  or  equal  to  the  start  time  of 
the  first.  The  precedes  association  is  defined  with  the  following  Z  static  schema: 
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Precedes - - - 

precedes  :  Job  <->  Job 

V(ji,j2)  £  precedes  •  ji. outputs  D  j2. inputs  ^  {  }A 
ji. end-time  <  j2. start-time 

V(ji,j2)  €  precedes  — >  3d1  £  (ji. outputs  A  j2.inputs) 


3.6  Automated  Tasks 

In  the  object  model  proposed  by  Hunt  and  Sarchet  (12,  28),  the  attributes  which  describe  the 
time  and  accuracy  of  a  Worker  performing  a  Job  were  associated  with  the  assignment  association. 
This  imposed  the  limitation  that  for  any  Job  to  have  a  time  or  accuracy,  there  must  be  a  Worker  to 
Job  assignment.  It  was  desired  to  have  the  ability  to  model  an  automated  Job  as  being  accomplished 
without  the  need  for  a  Worker.  Therefore,  it  was  decided  to  move  the  time  and  accuracy  attributes 
to  the  Job.  This  allows  time  and  accuracy  attributes  to  be  assigned  independent  of  a  Worker  to 
Job  assignment,  thus  allowing  an  automated  Tool  to  perform  the  Job.  Also  added  to  the  attributes 
associated  with  the  Job  object  was  the  automated_time  attribute.  This  attribute  designates  the 
actual  amount  of  time  required  to  do  the  Job  if  it  is  automated  and  is  disregarded  if  the  Job  is  done 
by  a  Worker. 

If  a  Job  is  automated,  a  reasonable  accuracy  must  be  established.  This  accuracy  may  be  Job 
specific.  In  most  cases,  however,  the  accuracy  will  most  likely  be  very  near  100  percent.  Probability 
and  reliability  statistics  will  be  needed  to  correctly  assign  accuracy  values  for  each  Job. 
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3. 7  Efficiency  and  Effectiveness  Metrics  for  the  Organization 


The  efficiency  and  effectiveness  of  an  organization  can  be  interpreted  in  many  different  ways 
depending  on  the  organization  and  the  persons  making  the  evaluation.  An  initial  assessment  by 
Hunt  and  Sarchet  (12,  28)  was  made  to  determine  what  was  needed  to  produce  an  overall  assessment 
and  to  provide  the  necessary  feedback  to  give  the  system  user  insight  into  how  well  allocated  the 
resources  were  and  whether  or  not  automation  provided  any  value.  This  assessment  determined 
that  the  following  broad  categories  of  feedback  measures  were  important  to  aid  in  the  evaluation 
of  an  organization  and  determine  how  automation  added  value: 

1.  Timing 

2.  Worker  Efficiency 

3.  Accuracy 

4.  Critical  Path 

The  definitions  for  these  metrics  are  in  (12,  28).  In  the  next  section,  the  Z  code  to  formally  express 
and  compute  these  metrics  are  presented. 

3.7.1  Z  Code  for  the  Timing  Metrics.  Analysis  of  the  timing  measures  yielded  the 

following  timing  metrics  along  with  the  Z  code  to  formally  describe  them. 

1.  Shortest  Job 

min  j.time 

V  j€  job  set 

2.  Longest  Job 

max  j.time 

Vjejobset 

3.  Shortest  Task 

min  t.time 

V  t^taskset 
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4.  Longest  Task 


max  t.time 

V tttaskset 

5.  Shortest  Project 

min  p.time 

V  ptprojectset 

6.  Longest  Project 

max  p.time 

V  pEprojectset 

7.  Total  Time  to  Complete  Project 

t.time 

V  t£task$et 

The  approach  to  computing  the  Total  Amount  of  Time  for  a  Project  is  to  accumulate  the 
times  for  each  individual  Task.  The  Z  code  to  calculate  this  follows: 

t.time 

V  ttztashset 

3.7.2  Z  for  Calculating  Worker  Efficiency.  Analysis  of  the  Worker  Efficiency  measures 

yielded  the  following  efficiency-related  metrics,  each  of  which  is  described  in  further  detail: 

1.  Time  Spent  Working  for  Worker  w1 

j.time 

V(wi , j)€assignment 

2.  Worker  Efficiency  for  Worker  Wi 

Time  Spent  W or king(w\)/ Project. time 

Time  Spent  Working  is  calculated  for  each  Worker  by  accumulating  the  individual  times  spent 
performing  Jobs.  Worker  Efficiency  is  the  ratio  between  Time  Spent  Working  and  the  amount  of 
time  required  to  complete  the  Project. 


3.7.3  Z  for  Calculating  the  Accuracy  Metrics.  Analysis  of  the  accuracy  measures  yielded 

the  following  accuracy-related  metrics,  each  of  which  is  described  in  further  detail: 

1.  Least  Accurate  Job 

min  j. accuracy 

V  jEjobset 

2.  Most  Accurate  Job 

max  j. accuracy 

Vjejobset 

3.  Least  Accurate  Task 

min  t. accuracy 

V  tEtaskset 

4 .  Most  Accurate  Task 

max  t.  accuracy 

V  tEtaskset 

5.  Overall  Accuracy  for  Project 

(  ^  t.accuracy)/ff{taskset ) 

V  tEtaskset 

3.8  AF  Wing  Refine  Model 

The  resulting  Refine  implementation  of  the  model  is  included  in  Appendix  A.  Due  to  time 
constraints,  the  full  Z  specifications  were  not  implemented.  However,  many  of  the  key  aspects  of 
the  model  are  implemented  and  display  much  versatility  and  functionality. 

3.8.1  Objects  in  Refine.  The  mapping  of  the  Z  specifications  into  the  Refine  model 
produced  the  executable  version  of  the  model.  The  files  for  base  objects  in  Refine  were  typical. 
The  following  is  a  partial  example  of  the  Worker  file: 

! !  in-package (nRUM) 

!  !  in-grammar ( 7  user) 
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#1 1 


—  Object  Name:  Worker 

—  Specification  Date:  08/28/95 

—  Filename:  worker. re 

—  Specified  by:  Hibdon 


I  I# 

Uo  Define  base  sets  (types) : 

constant  AFSCS  :  set (string)  =  {  "33S3B",  "33S3C",  "4921"} 

°/o7o  Define  class  structure: 

var  Worker:  object-class  subtype-of  user-object 
var  wname:  map (Worker,  string)  =  {||} 
var  wafsc:  map(Worker,  string)  =  {||> 
var  wskill_level :  map (Worker,  integer)  -  {11} 
var  wavailability :  map(Worker,  boolean)  =  {||} 
var  wexperience:  map (Worker,  integer)  =  { I  I } 
var  weducation:  map(Worker,  integer)  =  { I  I > 
var  waptitude:  map (Worker,  integer)  =  { I  1} 

function  ShowWorker (w :  Worker)  = 

format  (TRUE,  "  Worker  name:  ~S~7.  Afsc:  "S~7.  skill.level:  ~d~7.  Availability:  ~b  "7. 
Experience:  ~d~7.  Education:  ~d~7.  Aptitude:  ~d~7."7.~7." ,  wname(w),  wafsc(w), 
wskill_level(w) ,  wavailability (w) ,  wexperience (w) ,  weducation (w) ,  waptitude(w) ) 

function  Setwname(w:  Worker,  n:  string)  = 

TRUE  — >  wname (w)  =  n 

7,7.  Checks  for  valid  afsc 

function  Setwafsc(w:  Worker,  a:  string)  = 
a  in  AFSCS  — >  wafsc (w)  =  a; 
a  "in  AFSCS  — >  wafsc (w)  =  undefined 

7,7o  Checks  boundary  ranges. 

function  Setwskill_level (w :  Worker,  s:  integer)  = 

(s  >=  1  &  s  <=  9)  — >  wskill_level (w)  =  s 

function  Getwskill_level(w:  Worker):  integer  = 
wskill_level(w) 
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3.8.2  Creating  Aggregate  Classes.  Aggregate  objects  are  declared  in  the  same  fashion 
as  primitive  objects,  that  is  they  are  declared  of  type  object-class  and  subtype  of  user-object. 
The  Organization  is  an  example  of  such  an  aggregate  object.  The  Organization  is  composed  of  a 
ToolS et,  a  Workforce ,  a  ManningPlan ,  and  a  ProjectSet.  It  also  contains  the  mappings  for  all  of 
the  associations  among  all  objects.  The  declaration  for  the  Organization  is  in  Appendix  A.  Notice 
that  some  of  the  variables  of  the  Organization  are  mappings  from  the  Organization  to  other  already 
declared  objects.  This  is  the  method  for  representing  aggregation  in  Refine. 

3.8.3  Testing  Refine  Model.  The  Refine  implementation  of  the  domain  model  was  tested 
using  a  variety  of  tests.  Initially,  test  drivers  were  written  for  the  individual  objects  as  they  were 
developed.  These  tests  mainly  consisted  of  functions  to  initialize  and  modify  the  attributes  of  the 
individual  objects.  These  tests  evolved  to  include  the  range  constraints  of  the  attributes  and  finally 
checked  the  specific  behavior  of  the  objects.  A  sample  test  function  for  the  Worker  object  follows: 

! !  in-package ("RUM) 

! !  in-grammar ( * user) 

#1  I 


—  Object  Name:  Worker  test  routine 

—  Specification  Date:  08/28/95 

—  Filename:  testworker . re 

—  Specified  by:  Hibdon 

—  Based  on:  Worker  (950505) 

—  History: 

—  08/28/95  (Hibdon):  original  design. 

—  Test  program  for  Worker 

I  I# 

var  myworker:  Worker  =  NewWorkerQ 
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function  TestWorkerl (w:  Worker)  = 

SetwNameCw,  "Joe  Smith"); 

SetwAfsc(w,  "33S3B") ; 

Setwskill_level(w,  5) ; 

SetwAvailability (w,  TRUE); 

SetwExperience (w ,  10) ; 

SetwEducation(w,  15) ; 

SetwAptitude(w,  125)  ; 

ShowWorker (w) 

•///, - End  of  test  worker - 

After  the  completion  of  the  Organization  object  and  the  transformation  of  much  of  the  Z 
specifications,  it  was  necessary  to  develop  a  test  which  checked  the  full  functionality  of  the  model. 
This  was  a  very  extensive  step  and  required  many  additional  functions  be  created  to  set  up  the 
system  to  provide  the  required  members  in  the  appropriate  associations  to  allow  the  observation  of 
the  model.  For  example,  to  model  an  actual  assignment  of  a  Worker  to  a  Job  required  the  function 
AddAssignment  which  created  the  Assignment  object  and  associated  the  specified  Worker  and  Task 
as  attributes  of  the  object.  The  model  as  developed  actually  provides  for  a  snapshot  in  time  of 
the  Organization  and  its  parts.  It  does  not  actually  have  dynamic  behavior.  A  complete  set  of 
associations  and  objects  must  be  in  place  for  the  model  to  execute. 

The  test  functions  in  the  Refine  environment  were  used  to  verify  that  the  model  behaved  as 
expressed  in  the  Rumbaugh  and  Z  specifications.  The  results  of  all  conducted  tests  confirmed  that 
the  Refine  portions  of  the  model  behaved  as  expected. 

3. 9  Summary 

This  chapter  has  described  the  methodology  for  creating  a  formal  model  of  an  AF  organi¬ 
zation.  The  three  main  phases  of  the  methodology,  OMT,  Z  specification,  and  transformation  to 
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Refine,  were  described  in  detail  and  the  resulting  model  was  presented.  The  domain  model  of  the 
AF  organization,  consisting  of  the  Rumbaugh  OMT,  the  Z  specification,  and  Refine  implementa¬ 
tion,  served  as  the  basis  for  analysis  of  the  described  methodology.  Chapter  IV  provides  an  analysis 
of  the  methodology  used  to  develop  the  model  as  well  as  analysis  of  the  model  itself. 
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IV.  Analysis  and  Results 


4-1  Introduction 

The  domain  model  of  an  Air  Force  organization  which  was  the  result  of  the  described  method¬ 
ology  is  discussed  in  Chapter  III.  As  discussed  in  Section  1.2,  the  sponsor  needed  decision  making 
support  for  allocating  resources  and  determining  the  effects  of  automation.  To  provide  this  support, 
the  proposed  formal  methodology  for  developing  an  organization  model  was  followed.  The  previous 
attempt  at  providing  this  support  was  developed  using  Ada  83  by  Hunt  and  Sarchet.  The  Ada 
version  required  a  procedural  simulation  to  run  for  actual  evaluation  of  the  model.  That  version 
also  included  the  inherent  maintainability  problems  associated  with  any  procedural  language.  All 
updates  to  the  model  require  the  maintainer  to  locate  and  change  all  dependencies  related  to  any 
modification  of  the  model.  This  is  not  only  difficult  but  also  time  consuming.  In  the  Refine  model, 
the  environment  locates  dependencies  and  makes  the  appropriate  internal  changes  necessary  for 
the  new  requirements  defined  in  maintenance.  This  equates  to  redevelopment  of  a  system  through 
a  changed  set  of  system  requirements.  The  aim  of  this  analysis  is  to  examine  the  overall  method¬ 
ology  proposed  for  developing  a  formal  model  of  an  organization  and  to  evaluate  whether  or  not 
the  goals  of  the  model  were  actually  met.  This  analysis  focuses  on  the  goals  of  the  model  and  the 
contributing  factors  to  the  related  successes  and  failures  in  achieving  these  goals. 

4-2  Analysis  of  Model 

The  Rumbaugh  model  developed  during  this  research  is  certainly  more  comprehensive  than 
the  previous  model.  The  added  objects  and  attributes  make  it  more  truly  reflect  the  real-world 
AF  wing.  Additionally,  the  model  is  more  versatile  and  maintainable.  The  objects  and  attributes 
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ensure  that  the  model  has  a  higher  probability  of  reuse  in  different  domains.  This  model  may  be 
able  help  leaders  more  accurately  assess  the  status  of  their  organizations.  This  model  has  many 
uses,  from  the  assessment  of  the  assignment  of  workers  and  tools  to  accomplish  jobs  to  providing 
organizational  metrics  to  leaders.  The  model  has  the  ability  to  assess  overall  organization  metrics 
such  as  unit  readiness,  unit  effectiveness,  and  unit  efficiency.  If  used  in  conjunction  with  an  optimiz¬ 
ing  scheduling  environment  such  as  KIDS/SpecWare  (5),  the  model  could  be  enhanced  to  include 
evaluating  assignment  schedules.  It  could  also  then  be  used  to  assess  the  impact  of  automation 
tools  on  various  assignment  schedules.  The  model  will  also  be  useful  in  the  assessment  of  various 
proposed  schedules  for  worker,  tool,  and  job  assignments  and  their  impact  on  the  organization. 

The  improved  model  implemented  in  Refine  is  easier  to  modify  for  use  by  other  organizations. 
This  is  due  to  the  object-oriented  approach  taken  in  the  design  phase  and  the  environment  chosen 
for  implementation.  Not  only  is  the  model  reusable,  so  is  the  methodology  used  to  develop  the 
model.  If  necessary,  a  system  developer  could  use  the  proposed  methodology  from  the  beginning 
to  design  his  or  her  own  domain-specific  organizational  process  model  and  finish  with  a  set  of 
executable  specifications.  Modification  and  maintenance  of  the  model  involves  simply  making  the 
changes  to  the  specifications.  The  changes  could  be  possibly  made  at  The  Refine  level  and  back 
documented  into  the  Z  and  Rumbaugh  model  or  carried  forward  from  the  Rumbaugh  model  to 
the  Refine.  An  evolutionary  or  incremental  approach  to  system  development  should  be  simple  to 
implement  with  the  availability  of  a  functional  prototype  system  to  check  behavior  throughout  the 
development  when  using  this  methodology. 

An  initial  goal  was  to  make  the  model  more  representative  of  the  real-world  through  further 
domain  analysis  and  improvements  to  the  Rumbaugh  model.  Due  to  the  past  experience  of  the 
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researcher  and  the  knowledge  gained  by  the  previous  research  of  Hunt  and  Sarchet  (12,  28),  it  was 
possible  to  make  great  strides  in  this  area.  The  new  object  model  contains  increased  numbers  of 
objects  and  associations  as  well  as  more  relevant  object  and  association  attributes.  These  include 
the  added  Project  and  Task  objects  which  not  only  allow  for  the  collection  of  intermediate  level 
results  but  also  allow  the  flexibility  to  overcome  the  previous  limitations  of  assigning  only  one 
Worker  or  Tool  to  a  Job .  This  is  done  by  having  the  Job  object  be  the  smallest  possible  piece  of 
work  to  accomplish.  The  ToolSet ,  ManningPlan ,  and  Workforce  objects  were  added  to  provide  a 
more  accurate  method  for  determining  the  Organization’s  overall  unit-readiness.  The  Using  and 
Qualified-On  associations  were  included  to  ensure  that  Worker  to  Tool  relationships  that  were 
relevant  to  the  assigning  of  Tool- Worker- Job  combinations  were  done  in  a  valid  manner.  This  was 
to  ensure  that  the  proper  Worker  was  using  a  Tool  he  or  she  is  Qualified-On.  Also,  a  similar 
relationship  was  modeled  between  the  Worker  and  the  Job  objects  through  the  Qualified— For  and 
Assignment  associations.  Not  only  does  this  ensure  that  a  qualified  Worker  is  Assigned  to  the  Job , 
it  also  has  the  additional  information  contained  in  the  attributes  of  the  Qualified-For  association 
which  provides  specific  information  pertaining  to  the  amount  of  time  and  degree  of  accuracy  a 
particular  Worker  is  expected  to  have  in  the  performance  of  a  particular  Job.  A  very  similar 
relationship  can  be  seen  in  the  Supports  and  Assigned  associations  between  the  Tool  and  Job 
objects.  The  time  and  percentage  attributes  of  the  Supports  association  indicate  how  much  time  can 
be  saved  on  a  particular  Job  by  using  a  particular  Tool.  These  additional  objects  and  associations 
have  helped  achieve  some  of  the  goals  of  this  research  by  improving  the  realism  of  the  model. 

The  review  of  operations  research  literature  exposed  many  of  the  areas  which  were  improved. 
These  included  the  approach  to  calculating  overall  unit  readiness  and  the  addition  of  an  intermediate 
level  work  unit  to  allow  for  a  Project  object  to  be  composed  of  Task  objects  which  are  further 
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composed  of  Job  objects.  The  Ada  model  implementation  is  limited  to  assigning  a  single  Worker  to 
a  Task  and  single  Tool  to  a  Task  In  reality,  several  Workers  may  actually  perform  a  Task  in  a  given 
Project  and  several  Tools  may  be  used  also.  This  is  also  accounted  for  through  the  intermediate 
level  Task  object  which  is  composed  of  several  Job  objects  which  have  been  defined  as  the  smallest 
unit  of  work.  This  model  also  provides  for  intermediate  level  metrics  to  use  in  the  derivation  of 
higher  level  object’s  attributes. 

The  addition  of  the  dynamic  model  to  the  OMT  provides  for  the  developer  to  realize  the 
states  and  actions  necessary  for  the  model  to  behave  in  the  desired  fashion.  This  was  helpful  in  the 
formal  process  by  identifying  which  functions  would  be  required  for  the  model.  However,  during  the 
formal  development  of  the  model,  the  dynamic  model  was  seen  as  only  necessary  for  understanding 
system  behavior  and  was  not  used  in  the  final  model.  The  model  was  able  to  capture  the  required 
information  without  the  need  to  simulate  dynamic  behavior. 

4-3  Analysis  of  Methodology 

4.3.1  Contributions  to  Success.  The  development  of  the  Rumbaugh  model  was  a  very 
helpful  and  necessary  step  in  the  methodology.  Not  only  was  it  the  perfect  way  to  capture  the 
domain  information,  it  was  a  great  aid  in  the  visualization  of  the  model  to  be  developed.  If  the 
domain  information  was  not  captured  and  collected  in  an  object-oriented  manner,  this  research 
would  have  stood  little  chance  of  success.  Also,  without  some  sort  of  visual  representation  of  the 
desired  system,  development  would  be  difficult  if  not  impossible,  and  the  documentation  of  design 
decisions  and  resulting  maintenance  of  the  model  would  also  be  very  difficult. 
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Another  key  contributor  to  the  successful  implementation  of  the  model  in  the  Refine  en¬ 
vironment  was  the  transformation  of  the  OMT  model  to  Z  schemas.  The  Z  schemas  allow  the 
developer  to  begin  thinking  functionally  as  opposed  to  the  more  traditional  manner:  procedurally. 
The  mathematical  notations  and  descriptions  of  the  system  provide  the  initial  construct  needed  to 
implement  the  “what”  instead  of  the  “how”  for  the  desired  model.  This  transformation  led  directly 
to  successful  implementation  of  the  model  in  a  formal  environment.  This  made  the  transforma¬ 
tion  to  the  Refine  executable  model  almost  a  one-to-one  translation  of  the  Z  schemas  which  were 
by  nature  declarative  as  opposed  to  procedural.  The  Refine  environment  provides  the  ability  to 
implement  a  specification  of  a  system  using  constructs  very  similar  to  the  specifications  in  the  Z 
model.  The  translation  phase  of  the  system  development  was  the  most  challenging  but  also  the 
most  rewarding.  Many  of  the  model  specifications  could  be  expressed  as  “what”  the  system  was  to 
do  as  opposed  to  “how”  the  system  was  to  do  it.  The  ability  of  the  Software  Refinery  environment 
to  deduce  the  “how”  from  the  “what”  was  a  key  to  the  success  of  this  approach. 

The  Software  Refinery  environment  was  a  great  asset  in  the  incremental  approach  to  devel¬ 
oping  the  executable  model  in  Refine.  Changing  and  implementing  different  system  specifications 
was  a  simple  process  which  required  only  modifying  the  desired  specifications  to  the  new  behavior 
and  a  two  keystroke  recompilation  prior  to  execution.  This  process  usually  requires  seconds  as 
opposed  to  minutes  or  even  hours  which  might  have  been  required  to  locate  and  change  all  of  the 
dependencies  in  a  classical  implementation  such  as  the  Ada  implementation.  The  next  six  func¬ 
tions  demonstrate  the  incremental  development  of  the  qualified—for  association.  Each  new  function 
definition  has  additional  requirements  specified  which  increase  the  capabilities  of  the  association. 

function 

SetQualif ied_For(qf :  Qualif ied_For ,  w:  Worker,  j:  Job, 
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ex_accuracy:  integer,  ex_time:  integer)  = 

TRUE  — >  (wqualif ied_f or(qf )  =  w  &  jqualif ied_f or (qf)  =  j  & 

expect_accuracy(qf )  =  ex_accuracy  &  expect_time(qf )  =  ex.time) 

This  first  increment  simply  accepts  input  and  sets  up  the  association  without  regard  for  what 
is  input. 


function  SetQualif ied_For2(qf :  Qualif ied.For ,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc_set(j)  &  wskill_level(w)  >=  jskill_level(j)  > 

(wqualif ied_f or (qf)  =  w  &  jqualif ied.for(qf)  =  j  &  expect _time(qf )  =  jbest_time(j)) 

The  second  increment  compares  the  afsc  and  skill— level  of  the  Worker  to  the  afscset  and 
skilUevel  of  the  Job.  If  this  comparison  is  okay,  the  function  then  uses  attributes  from  the  Worker 
and  Job  to  establish  the  qualified-for  association’s  expect-time  attribute  using  only  the  best-time 
attribute  of  the  Job. 


function  SetQualif ied_For4(qf :  Qualif ied.For,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc_set(j)  &  wskill_level (w)  >  jskill_level(j)  > 

(wqualif ied_f or (qf)  =  w  &  jqualif ied_f or (qf)  =  j  &  expect_time(qf )  =  jbest_time(j)) ; 
wafsc(w)  in  jafsc_set(j)  &  wskill_level(w)  =  jskill_level(j)  — > 

(wqualif ied_for(qf)  =  w  &  jqualif ied_f or (qf)  =  j  &  expect_time(qf )  =  javerage.time(j)) ; 
wafsc(w)  in  jafsc_set(j)  &  wskill_level(w)  <  jskill_level(j)  > 

(wqualif ied_f or ( qf )  =  w  &  jqualif ied_for(qf)  =  j  &  expect_time(qf )  =  jworst.time(j)) 

This  increment  now  makes  the  association  assignment  based  on  the  Job’s  average-time  and 
worst-time  attributes. 


Tl.  Add  qualif ied_f or  expect_accuracy  checks  and  assignments, 
function  SetQualif ied_For4a(qf :  Qualif ied.For,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc_set(j)  &  wskill_level(w)  >  jskill_level(j)  — > 

(wqualif ied_f or (qf )  =  w  &  jqualif ied_f or (qf)  =  j  &  expect_time(qf )  = 
jbest_time(j)  &  expect_accuracy (qf )  =  jbest_accuracy(j ) ) ; 
wafsc(w)  in  jafsc_set(j)  &  wskill_level(w)  =  jskill_level(j)  — > 

(wqualif ied_for(qf)  =  w  &  jqualif ied_f or (qf)  =  j  & 

expect.time(qf)  =  javerage_time(j)  &  expect_accuracy(qf )  =  javerage_accuracy(j)) ; 
wafsc(w)  in  jafsc_set(j)  &  wskill_level (w)  <  jskill_level(j)  — > 

(wqualif ied_f or (qf)  =  w  &  jqualif ied_for(qf)  =  j  & 
expect_time(qf )  =  jbest_time(j)  &  expect_accuracy (qf)  =  jworst_accuracy(j ) ) 

This  increment  has  the  additional  checks  for  the  expect-accuracy  attribute. 
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•/,*/.  Added  axioms  to  allow  other  attributes  of  the  worker  and  job  to  affect  the  expect  .time 
and  expect.accuracy  attributes  of  the  qualif ied.f or  association, 
function  SetQualif ied_For5(qf :  Qualif ied.For ,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc.set(j)  &  wskill_level(w)  >  jskill_level(j )  > 

(wqualif ied.f or(qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect_time(qf )  =  jbest.time(j)) ; 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  =  jskill.level(j)  — > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect .time (qf )  =  javerage.time(j)) ; 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  <  jskill.level(j)  > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect_time(qf )  =  jbest.time(j)) ; 
wafsc(w)  in  jafsc.set(j)  &  weducation(w)  >=  10  &  j complexity (j )  <=  75  — > 

( (expect.time*  =  expect .time (qf )  — >  expect .time(qf)  =  expect.time*  +  20)  & 
(expect.accuracy*  =  expect_accuracy(qf )  — >  expect.accuracy (qf)  = 
expect.accuracy*  +  20)) 

This  final  incremental  development  of  the  SetQualified-For  function  now  includes  specifica¬ 
tions  which  take  into  account  the  impact  of  the  Worker’s  education  attribute  and  the  along  with 
the  Job’s  complexity  attribute  in  the  assigning  of  the  association’s  attributes.  It  should  be  noted 
that  this  type  of  development  allows  for  the  developer  to  verify  the  functionality  of  the  model  as 
it  is  being  developed.  Also,  many  more  similar  types  of  specifications  could  be  added  if  system 
requirements  change. 

The  ability  to  use  mathematical  constructs  and  set  former  notation  within  the  Refine  envi¬ 
ronment  allows  the  developer  to  build  powerful  and  complex  constructs  in  a  compact  and  efficient 
manner.  The  following  is  an  example: 

'/,%This  function  calculates  all  of  the  accuracy  attributes  for  jobs  in  the 
organization’s  jobset  based  on  the  worker-job  assignment  and  the  qualif ied.f or 
association  expect.accuracy  attribute.  Also  takes  into  account  the  tool-job 
assigned  association  and  the  supports  association  percentage  attribute. 


function  CalculateAccuracys(ol :  Organization,  projl:  Project)= 
enumerate  p  over  range (contents (org-assignment (ol) ) )  do 
j accuracy (Get JAssignment (p) )  <- 

GetExpect.Accuracy (Get Qualif ied.For (org-qualif ied.f or (ol) ,  Get JAssignment (p) ) ) 
+  percentage (GetSupports (org-supports (ol) ,  Get JAssignment (p) ) ) 

Maintenance  of  the  system  or  updating  the  model  from  sponsor  input  to  meet  changing 
requirements  is  accomplished  easily  using  the  current  methodology.  However,  after  initial  model 
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development  it  may  not  add  value  to  the  model  to  add  such  changes  to  the  Z  model  other  than  to 
document  design  changes. 

Compactness  of  the  necessary  code  to  extract  metrics  in  both  Z  and  Refine  were  great  when 
compared  to  the  Ada  code  to  accomplish  similar  objectives.  For  example,  the  Ada  pseudo  code 
generated  to  accomplish  the  setting  of  a  Task’s  predecessors  is  as  follows: 


Set„Predecessors 

begin 

for  all  tasks  do 

for  all  inputs  in  current  task  do 

for  all  tasks  other  than  current  task  do 
if  current  task’s  current  input  = 

any  output  from  current  other  task  then 
add  other  task  to  current  task’s  predecessor  list 
endif 
endloop 
endloop 
endloop 

end  Set_Predecessors 

While  the  Z  construct  needed  to  specify  the  same  objective  was  much  simpler. 


_ Precedes _ _ _ _ _ _ _ 

precedes  :  Job  Job 

V(ji,j2)  •  (juh)  €  precedes  — >  jx.outputs  Pi  j2 -inputs  ^  {  }  A  jx. end-time  <  j2-start-time 


The  corresponding  Refine  code  to  actually  implement  the  behavior  was  quite  easy  to  construct 
from  the  Z  specification. 


function  GetAllPrecedes (ps :  PrecedesSet) :  Set (Precedes)  = 

{pre  |  (pre:  Precedes)  (pre  in  contents (ps)  &  (j outputs (Get JlPrecedes (pre) )  intersect 
j inputs (Get J2Precedes (pre) )  ~=  {})  &  jend_time (Get JlPrecedes (pre) )  <= 
j  start _t ime (Get J2Precedes (pre) ) ) > 
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Another  comparison  of  Ada  versus  Z  and  Refine  appears  in  the  calculating  of  the  time  to 
complete  a  Project  The  following  comes  directly  from  (28):  “The  approach  for  calculating  the 
Total  Time  To  Complete  The  Scenario  is  to  trace  through  execution  of  the  scenario  keeping  track 
of  the  order  of  individual  task  execution  and  the  associated  times.  The  algorithm  for  computing 
this  metric  is  defined  as  follows: 


Scenario.Time  <-  0 

while  not  Scenario_Complete (Tasks)  loop 
loop  from  1  . .  Num_0f _Task 

if  Predecessors_Complete(Current_Task)  and 
Worker.Available (Selected_Worker)  and 
Tool_Available (Selected_Tool)  and 

Current _Task. Status  /=  Complete  then 

Current.Task  <-  In_Progress 
Selected_Worker. Available  <-  false 
Selected_Tool. Available  <-  false 

end  if 

Current .Task  <-  Next__Task 
end  loop 

Scenario. Time  <-  Scenario_Time  +  Shortest_Task .Time 
Shortest. Task  <-  Complete 
Selected_Worker. Available  <-  true 
Selected.Tool . Available  <-  true 

loop  from  1  . .  Num.Of .Tasks 

if  Current .Task . Status  =  In.Progress  then 

Current .Task . Time  =  Current.Task.Time  -  Shortest. Task .Time 
end  if 

Current_Task  <-  Next. Task 
end  loop 
end  loop  5 J 

Notice  the  amount  of  code  needed  for  the  Ada  version.  Note  that  in  the  Ada  version  the 
Scenario  is  equivalent  to  a  Project  in  the  Z  and  Refine.  The  same  information  is  captured  in  the 
following  Z  specification: 


total-time  =  ^  t.time 

V  tEtaskset 

The  amount  of  Z  necessary  is  small  due  to  the  fact  that  a  discrete  event  simulation  is  not  in  progress 
as  is  needed  for  the  Ada  implementation.  The  desired  behavior  is  simply  specified.  The  Refine  for 
the  same  specification  is  about  as  simple. 
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'/,%  Project  total  time  is  based  on  the  tasks’  times, 
function  Setptotal_time(pl :  Project)  = 

TRUE  — >  ptotal_time (pi)  <- 

reduce (+,  [ttotal.time (tl)  I  (tl:  Task)  tl  in  ptask.set (pi)] ) 

Notice  the  amount  of  information  captured  in  the  following  Refine  specification  which  is  used 
to  calculate  the  amount  of  time  spent  on  a  Project  so  far  giving  a  snapshot  view  of  the  time 
attribute. 

%*/,  Calculates  project’s  time  so  far  based  on  the  tasks 
function  Setptime_so_f ar (pi :  Project)  = 

Let  (temptask:  Task  =  arb({tl  |  (tl:  Task)  tl  in  ptask_set (pi)  k 
tstatus(tl)  =  ’in-process})) 

TRUE  — >  ptime_so_f ar(pl)  <-  tstart_time (temptask)  + 

twall_time (temptask)  *  tpercent_complete (temptask) 

During  the  Refine  transformation  phase  some  of  the  Z  schemas  specified  were  found  to  be 
redundant  or  specified  situations  which  would  never  be  possible.  This  somewhat  simplified  the 
transformation  but  added  time  necessary  to  make  these  observations  and  determine  if  the  specifi¬ 
cations  were  indeed  necessary  or  not. 

4.3.2  Limitations  to  Success.  One  of  the  key  limitations  to  the  development  process 
was  the  lack  of  a  Z  compiler  or  checker.  Several  problems  were  discovered  during  the  Refine 
implementation  that  were  incorrect  in  the  Z  schemas.  These  were  not  apparent  during  development 
of  the  Z  model  and  could  only  be  checked  by  the  developer  and  other  domain  specialists.  It  was 
then  necessary  to  correct  the  problems  discovered  in  the  Z  specifications  which  required  revisiting 
the  Z  model.  This  could  have  been  avoided  if  there  existed  the  ability  to  check  the  Z  schemas 
during  development.  This  further  limited  the  depth  of  the  development  possible  in  the  Refine 
model  due  to  the  time  requirements  to  revisit  the  Z.  This  could  be  attributed  to  the  limitations  of 
the  currently  available  tools  for  formal  development.  Much  current  research  is  concerned  with  the 
development  of  such  tools.  These  tools  should  greatly  increase  the  power  of  this  methodology. 

Although  the  Software  Refinery  Environment  does  much  work  for  the  model  developer,  it 
does  have  some  limitations.  Since  this  research  did  not  make  use  of  Refine’s  package  environment, 
any  object  attributes  named  within  the  current  environment  are  global.  Therefore,  common  object 
attributes,  such  as  name,  had  to  be  modified  from  the  Z  definitions  to  be  totally  different  (e.g. 
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toolname  and  taskname).  All  maps  declared  within  the  Refine  environment  without  the  use  of  pack¬ 
aging  are  global  thus  requiring  unique  naming  conventions  for  every  individual  object’s  attribute 
names. 

During  the  translation  of  the  Z  schemas  into  Refine,  occasionally  specifications  were  discov¬ 
ered  which  the  Software  Refinery  Environment  could  not  decide  how  to  interpret  correctly.  For 
example,  it  could  not  decide  what  to  do  with  the  attribute  tstatus(tl)  in  the  following  specification. 
The  Refine  environment  wanted  to  know  what  the  value  should  be  so  that  it  could  set  it,  not  just 
what  it  could  not  be.  Apparently,  it  requires  more  information. 

’/oyo  Refine  cannot  determine  how  to  do  the  following: 

(s  ~=  ' finished)  — >  (pc  <  100) 

(ex  j  in  t job_set (tl) ) (jstatus(j)  ~=  'finished)  => 
tstatus(tl)  ~=  'finished 

It  appears  that  there  currently  exists  a  line  between  the  common  procedural  style  and  a  style  which 
contains  only  pure  declarative  specifications.  At  times,  Refine  has  some  trouble  crossing  this  line. 

4.4  Summary 

This  chapter  has  analyzed  the  goals  of  this  research,  the  contributions  to  successful  accom¬ 
plishments  of  these  goals,  and  some  of  the  limitations  which  left  some  goals  unreachable.  This 
analysis  has  resulted  in  identifying  the  helpful  and  valuable  techniques  employed  in  the  formal 
development  process:  developing  a  visual  model  via  Rumbaugh,  formally  defining  the  model  in 
Z  mathematical  notation,  and  transforming  the  model  into  executable  specifications  in  Refine.  A 
comparison  to  an  Ada  implementation  displayed  the  great  diversity  and  compactness  of  the  formal 
specifications.  This  chapter  has  also  identified  the  limitations  of  this  methodology:  the  lack  of 
formal  tools,  and  difficulty  in  fully  defining  a  model’s  full  behavior.  The  methodology  and  resulting 
formal  model  are  the  basis  for  extracting  the  characteristics  of  the  methodology  and  model  which 
may  lead  to  a  more  generalized  approach  to  apply  this  methodology  to  organizations  outside  of  the 
AF  domain.  The  next  chapter  discusses  the  generalization  of  the  methodology  and  model. 
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V.  Generalization  and  Reusability  of  Model 

5.1  Introduction 

The  previous  chapter  provided  an  analysis  of  the  methodology  and  the  resulting  model.  This 
chapter  describes  how  the  methodology  and  model  might  be  generalized  to  provide  for  maximum 
reusability.  In  the  original  plan,  the  methodology  was  to  be  tested  on  another  domain.  However, 
time  constraints  did  not  allow  such  a  test.  This  chapter  also  discusses  the  domain  specific  aspects 
of  the  model.  Next,  the  modeling  methodology  and  its  generalization  are  discussed.  The  model 
and  its  components  are  examined  for  their  possible  reusability.  Finally,  a  proposed  use  of  the 
methodology  on  another  domain  is  discussed. 

5.2  Generalization  of  the  Modeling  Methodology 

The  methodology  followed  in  the  development  of  the  AF  organization  model  was  by  and 
large  a  very  general  concept  to  begin  with.  If  a  system  developer  felt  that  it  was  necessary  to 
begin  from  scratch  and  execute  the  methodology  from  the  ground  up,  it  would  not  be  a  difficult 
task.  The  first  phase  of  the  methodology  is  where  the  domain  specific  issues  are  brought  out.  The 
Rumbaugh  model  with  its  objects  and  system  behavior  essentially  drive  the  next  two  phases  of 
the  methodology.  In  the  domain  analysis  of  the  Rumbaugh  model,  the  required  attributes  and 
model  behavior  are  developed.  The  development  of  the  Z  schemas  follows  directly  from  the  given 
Rumbaugh  model,  and  as  previously  stated,  the  Refine  model  is  almost  a  one-to-one  transformation 
of  the  Z  schemas.  However,  the  approach  and  resulting  model  are  quite  general  and  easily  applicable 
to  a  large  number  of  organizations  which  by  nature  are  composed  of  Jobs ,  Tools ,  Workers,  and  the 
assignment  of  Workers  and  Tools  to  accomplish  Jobs.  Although  the  methodology  is  easy  enough 
to  use,  the  developer  should  first  look  at  reusing  an  existing  model. 

5.3  Reuse  of  Model 

The  existing  object  model  developed  for  the  AF  wing  domain  illustrated  in  Figure  13  might 
at  first  appear  to  be  very  domain  specific.  However,  a  careful  analysis  of  the  model,  beginning  with 
the  basic  objects  will  reveal  that  the  model  is  adaptable  for  use  in  many  other  organizations. 
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Figure  13.  Object  Model 
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5.3.1  Basic  Objects.  The  most  basic  objects  which  make  up  the  model  are  the  Job, 
Worker,  and  Tool.  When  examining  the  Job,  most  of  the  attributes  it  contains  are  general  in 
nature  and  could  be  used  to  describe  almost  any  job  in  any  domain.  The  two  attributes  which  look 
domain  specific  are  the  afscset  and  the  skilUevel.  An  afsc  is  the  job  descriptor  or  code  for  the  class 
of  worker  who  is  preferred  to  accomplish  this  Job.  But,  on  further  review,  almost  any  organization 
which  has  multiple  different  jobs  to  accomplish  has  some  criteria  for  determining  the  workers  who 
can  accomplish  the  Job.  This  might  be  done  through  the  use  of  a  job  number,  word  description, 
or  organization  code.  The  method  used  in  the  organization  can  easily  be  adapted  into  the  existing 
model  through  the  changing  of  the  attribute  and  possibly  its  type  declaration  if  necessary.  The 
same  can  be  said  for  the  skill-level  attribute.  If  an  organization  distinguishes  between  various  skills 
of  workers  within  the  same  job  code,  then  it  can  use  the  existing  skilUevel  attribute.  If  it  is  not 
used,  then  it  can  be  ignored. 

Other  basic  objects  are  the  Worker,  Position,  and  Tool.  The  attributes  of  these  objects  can 
also  be  seen  to  cover  many  domains.  Again,  the  afsc,  afscset,  and  skilUevel  attributes  are  the  only 
domain  specific  ones.  These  can  also  be  easily  tailored  to  meet  the  needs  of  a  different  domain.  The 
additional  attributes  of  the  Worker  and  Tool  are  used  to  further  distinguish  between  the  abilities 
of  particular  workers  and  Tools  and  in  the  establishment  of  other  object  and  association  attributes. 
These  attributes  are  also  tailorable  or  removable  for  a  particular  domain.  This  shows  that  the  basic 
objects  of  the  model  are  indeed  quite  general  in  nature.  These  basic  objects  are  used  to  compose 
the  aggregate  objects  of  the  model.  The  next  section  examines  these  aggregate  objects. 

5.3.2  Aggregate  Objects.  The  aggregate  objects  of  the  model  are  composed  of  sets  of  basic 
objects  or  possibly  of  other  aggregate  object  as  in  the  case  of  the  Organization.  These  too  can  be 
seen  as  possible  to  use  in  many  domains.  Almost  every  Organization  will  have  Projects  to  complete 
along  with  a  Workforce  and  ToolSet  to  accomplish  the  Projects.  Most  Organizations  also  have  a 
desired  ManningPlan  which  is  the  desired  composition  of  the  actual  Workforce.  This  is  used  for 
organization  leaders  to  assess  the  decisions  made  in  hiring  and  firing  as  well  as  in  the  readiness  of 
the  organization.  The  attributes  of  these  aggregate  objects  are  almost  exclusively  derived  attributes 
based  on  attributes  of  the  basic  objects  which  means  that  the  lower  level  attributes  are  read  only 
from  the  aggregate  object’s  view.  The  attributes  all  are  common  to  many  organizations  and  in  fact 
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cover  a  wide  variety  of  object  properties.  The  Organization  level  aggregate  object  can  be  easily 
modified  to  contain  more  attributes  to  encompass  more  domain  specific  metrics.  Also,  the  existing 
attributes  of  the  Organization  can  be  modified  for  differing  domain  applications. 

5.3.3  Associations.  The  associations  of  the  model  cover  a  variety  of  uses  within  the 
model.  They  encompass  many  possible  relationships  between  the  object  which  may  be  useful  for 
a  particular  domain.  For  instance,  if  an  organizational  leader  wished  to  identify  which  Workers 
were  Qualified-On  which  Tools ,  then  this  information  is  available  the  the  association.  A  deci¬ 
sion  maker  might  also  desire  to  know  what  Workers  are  Qualified-For  what  Jobs  along  with  the 
expected-accuracy  and  expected-time  that  the  Worker  would  have  in  accomplishing  the  Job  to  aid 
in  deciding  who  to  assign.  Many  other  similar  associations  exist  in  the  current  model.  This  may  be 
seen  as  overkill;  however,  the  associations  deemed  to  be  unnecessary  for  a  particular  domain  can 
easily  be  deleted  from  the  model.  These  associations  can  be  modified  or  tailored  for  a  particular 
domain  application  just  as  easily  as  the  objects  in  the  model. 

5.3.4  Metrics.  The  metrics  specified  within  the  model  include  unit-readiness ,  unit-efficiency , 
and  unit-effectiveness.  These  metrics  are  very  broad  and  can  have  a  variety  of  meanings  within 
different  domains.  However,  the  specifications  for  the  metrics  can  be  easily  modified  to  capture  the 
information  necessary  for  the  particular  domain  of  interest.  Also,  any  new  metrics  needed  for  the 
domain  can  be  added  to  the  specifications. 

5.4  Proposed  Reuse  of  Methodology  and  Model 

Consider  the  organizational  structure  at  an  institute  for  higher  learning  such  as  AFIT.  AFIT 
can  be  considered  an  organization  composed  of  Workers:  faculty,  secretaries,  administrators,  etc., 
Jobs :  teach  courses,  type  letters,  evaluate  instructors,  etc.,  and  Tools:  overhead  projectors,  type¬ 
writers,  computers,  etc.  The  Tools  and  Workers  are  used  to  accomplish  the  Jobs  of  the  Organization 
(AFIT).  Implementing  the  proposed  three  phase  methodology  would  require  minimum  participation 
from  an  AFIT  domain  expert.  The  expert  would  need  to  aid  the  system  developer  in  identifying 
the  domain  specific  objects  along  with  the  attributes  necessary  to  describe  them.  Next,  the  do¬ 
main  expert  must  help  identify  the  pertinent  associations  between  the  objects  which  are  needed 
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for  the  Rumbaugh  object  model.  After  the  object  model  is  complete,  the  dynamic  model  must  be 
developed  to  describe  the  behavior  and  states  the  object  can  exhibit.  The  final  task  for  the  domain 
expert  is  in  the  defining  of  the  actions  of  the  dynamic  model  in  the  functional  model. 

Now,  with  a  complete  Rumbaugh  model,  the  methodology  can  be  continued  mainly  by  the 
system  developer  with  limited  interaction  with  the  domain  expert.  The  model  developer  needs 
to  transform  the  Rumbaugh  model  into  the  equivalent  formal  Z  schemas  to  progress  towards 
the  executable  Refine  model.  Any  discrepancies  noticed  in  the  Z  schemas  can  be  worked  out 
between  the  domain  expert  and  the  system  developer.  Once  the  Z  specifications  are  complete,  the 
transformation  to  Refine  can  begin. 

The  incremental  development  of  the  Refine  model  will  be  helpful  in  allowing  the  domain 
expert  to  test  specifications  as  they  are  implemented  and  thus  verify  that  the  specifications  are  de¬ 
veloped  validly.  The  domain  expert  can  also  be  involved  in  the  incremental  testing  of  the  prototype 
system  as  it  is  developed.  The  developer  can  add  capabilities  to  the  model  in  an  organized  incre¬ 
mental  manner  all  the  while  making  sure  that  the  model  maintains  its  behavior  from  one  stage  to 
another  (regression  testing)  in  a  baselined  approach.  Once  the  model  is  complete,  verification  and 
validation  of  the  model  behavior  can  be  tested.  Once  testing  is  complete,  the  Z  specifications  can 
be  documented  into  final  form  as  the  specifications  of  the  executing  model  and  used  as  a  baseline 
for  the  development  of  a  system  to  implement  in  the  organization  on  the  desired  platform. 

5.5  Conclusion 

This  chapter  examined  the  domain  specific  aspects  of  the  methodology  and  resulting  model 
and  showed  how  these  aspects  are  not  as  domain  specific  as  they  might  at  first  appear.  The 
model  and  the  methodology  both  appear  to  be  readily  extendable  beyond  the  domain  of  the  AF 
wing.  This  chapter  has  also  presented  a  theoretical  model  development  cycle  for  a  more  specific 
AF  organization-  the  Air  Force  Institute  of  Technology.  This  was  shown  to  be  a  feasible  use  for 
the  proposed  methodology  and  could  be  used  to  develop  a  model  within  this  domain  and  probably 
many  others.  The  next  chapter  presents  the  overall  research  results  and  provides  recommendations 
for  future  research. 
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VI.  Conclusions  and  Recommendations 


6.1  Introduction 

This  chapter  summarizes  this  research’s  objectives  along  with  a  review  of  the  original  problem 
statement.  Next  is  a  comparison  of  this  research’s  objectives  to  its  accomplishments  based  on  the 
analysis  presented  in  Chapters  IV  and  V.  Finally,  suggestions  for  future  research  are  offered. 

6.2  Research  Summary 

Chapter  I  established  that  the  primary  purpose  of  this  research  was  to  demonstrate  the 
feasibility  and  benefits  of  applying  formal  methods  of  software  engineering  technology  to  the  Air 
Force  organization  structure.  This  came  directly  from  the  original  problem  statement. 

The  AF  has  not  made  use  of  existing  knowledge  based  software  engineering  and  formal  methods 
technology  which  could  provide  improved  information  concerning  the  status  of  their  commands  by 
using  the  formal  representation  and  assessment  of  an  AF  wing. 

More  specifically,  the  research  goals,  along  with  how  they  were  accomplished,  follows: 

•  Analyze  the  previously  existing  model  of  the  AF  wing  -  Improve  the  object  model,  dynamic 
model,  and  functional  model  using  the  formal  algebraic  language  Z.  The  literature  review 
exposed  many  areas  within  the  model  to  improve.  These  range  from  the  added  objects, 
attributes  and  associations  to  the  ability  to  calculate  enhanced  unit  metrics.  A  dynamic 
model  was  added.  Chapter  III  described  the  transformation  of  all  three  parts  of  the  Rumbaugh 
model  into  the  actual  Z  formal  specifications. 

•  Verify  and,  as  much  as  possible,  validate  the  modified  model  -  At  each  stage  of  development, 
the  model  was  analyzed  by  local  researchers  to  verify  that  the  model  and  its  behavior  were 
being  implemented  correctly.  Additionally,  each  iteration  of  the  development  process  was 
checked  against  the  previous  specifications  for  consistency.  This  ensured  that  the  Rumbaugh 
model,  Z  specifications,  and  Refine  implementation  were  all  consistent. 

•  Translate  the  Z  formal  specifications  into  an  executable  specification  using  the  Software  Re¬ 
finery  Environment™  -  The  Z  specifications  presented  in  Chapter  III  were  mapped  into 
executable  Refine  code  during  the  process  model  development  methodology.  This  was  done 
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through  the  utilization  of  the  user-friendly  Software  Refinery  Environment™.  Although  not 
complete,  the  executable  model  displays  much  of  the  capabilities  of  the  model  expressed  in 
Z .  It  also  displays  the  power  and  efficiency  of  using  formal  methods  in  model  development. 

•  Generalize  the  model  by  identifying  the  domain  specific  constraints  and  dependencies  within 
the  model  -  Chapter  V  discusses  the  generalization  of  the  model  and  the  methodology.  Not 
only  is  the  methodology  shown  to  be  reusable  across  many  domains,  the  domain  specific 
portions  of  the  actual  model  itself  are  shown  to  be  easily  modifiable. 

•  Show  that  formal  methods  can  improve  the  process  of  evaluating  and  assessing  wing  metrics  - 
This  research  has  shown  that  the  model  developed  might  be  helpful  in  the  process  of  assessing 
an  organization.  The  methodology  can  be  used  to  develop  specific  organizational  process 
models  whose  behavior  can  be  observed  through  the  executable  Refine  implementation.  This 
model  can  be  developed  incrementally  while  the  added  or  changed  requirement  specifications 
can  be  validated  as  development  continues.  The  metrics  produced  by  the  model  can  be 
enhanced  during  development  or  at  future  dates  as  the  organizations  changes  and  grows. 

•  Identify  the  benefits  provided  by  the  use  of  formal  methods  -  During  the  development  of  the 
model,  it  was  shown  that  this  methodology  which  uses  formal  methods  and  constructs  leads 
directly  to  a  rapid  prototype  development  effort  which  allows  for  behavior  observation  and 
limited  executability  during  development.  With  other  formal  platforms  in  development  and  on 
the  horizon,  further  interfaces  with  other  platforms  will  certainly  lead  to  a  more  specification- 
oriented  development  environment  based  on  formal  approaches.  This  might  possibly  be  done 
in  conjunction  with  such  platforms  as  KIDS/SpecWare  (5)  or  through  Algebraically-Based 
Design  Refinement  environments  such  as  the  one  by  Wabiszewski  (31).  Also,  if  the  produced 
model  is  reused,  the  Rumbaugh  model  and  Z  specifications  will  be  reused  also.  This  leads 
directly  to  cost  savings  in  the  development  process.  It  also  leads  to  system  specifications 
which  have  a  mathematical  basis. 

6.3  Recommendations  for  Future  Research 

1.  Implement  the  methodology  on  an  organization  outside  of  the  AF  -  A  proposed  implemen¬ 
tation  of  the  methodology  is  presented  in  Chapter  V.  An  actual  attempt  to  model  such  an 
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organization  would  demonstrate  the  reuseability  of  such  a  methodology  and  would  greatly 
enhance  the  value  of  this  research  area. 

2.  Add  metrics  in  the  Refine  model  -  Many  of  the  metrics  described  in  the  Rumbaugh  model 
and  in  the  Z  specifications  were  not  implemented  in  the  Refine  model.  Adding  these  metrics 
and  validating  the  Z  specifications  for  the  metrics  would  make  the  Refine  model  closer  to 
achieving  the  goals  of  supporting  the  sponsor’s  needs. 

3.  Use  the  KIDS  and/or  SpecWare  tools  to  develop  a  scheduling  algorithm  which  optimizes  orga¬ 
nization  metrics  -  The  current  model  provides  a  snapshot  of  an  organization  with  an  already 
provided  assignment  schedule  of  Workers ,  Tools ,  and  Jobs.  If  this  model  could  be  interfaced 
with  a  platform  such  as  KIDS  or  SpecWare,  there  might  exist  a  manner  in  which  to  create  an 
optimized  scheduling  algorithm  which  maximizes  the  specified  unit  metrics.  This  would  pro¬ 
vide  feedback  for  the  organization  leaders  in  the  area  of  optimizing  schedules  and  identifying 
automation  impacts. 

4.  Take  the  development  methodology  one  step  further  to  the  translation  of  the  Refine  model  into 
an  implementation  in  a  fieldable  language  such  as  Ada95  -  The  Software  Refinery  Environment 
is  not  an  AF  approved  new  system  development  platform.  However,  research  is  leading 
to  the  development  of  transformation  systems  which  will  produce  executable  code  of  the 
desired  format,  Ada95,  from  Refine  code.  This  would  then  make  possible  the  placing  of  the 
implemented  systems  at  the  organization  for  use  by  leaders. 

5.  Add  a  new  Job ,  Task ,  or  Project  into  the  model  in  real-time ,  while  the  current  Project  is 
being  accomplished  -  Since  real-time  taskings  have  a  great  impact  on  leadership  decisions,  the 
ability  to  model  such  events  would  greatly  enhance  the  usefulness  of  the  model.  This  ability 
would  increase  the  realism  of  the  model. 

6.  Add  preemptive  scheduling  -  If  real-time  taskings  were  added,  it  would  be  desirable  to  resched¬ 
ule  Jobs ,  Tools ,  and  Workers.  This  would  be  necessary  to  allow  for  the  real-time  tasking  to 
be  dealt  with  in  the  proper  manner. 

7.  Continue  validation  of  the  model  -  The  model  was  not  validated  by  PACAF  domain  experts. 
This  model  and  its  behavior  should  be  validated  not  only  by  the  domain  experts  but  by 
different  AF  organizations  to  determine  whether  they  have  properly  captured  the  behavior  of 
the  organization.  This  is  a  necessary  step  in  determining  the  true  reusability  and  accuracy 
of  this  methodology. 


6.4  Final  Comments 

This  research  is  important  because  wing  decision  makers  do  not  currently  have  a  way  to 
systematically  represent  how  an  organization  performs  its  mission.  This  has  led  to  the  development 
of  some  software  systems  which  are  short-sighted  or  very  limited.  The  domain  models  developed  in 
this  research  have  captured  knowledge  about  the  key  objects,  operations,  and  relationships  inherent 
to  the  typical  AF  organization.  The  methodology  for  developing  such  models  has  been  shown  to 
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possibly  be  beneficial  to  organizations  outside  the  AF  domain.  This  formal  development  process 
is  simpler,  more  efficient,  more  maintainable,  and  more  reusable  than  more  traditional  methods  of 
development. 

This  research  successfully  developed  a  domain  model  of  a  typical  AF  organization  and  showed 
how  the  use  of  formal  methods  of  software  engineering  could  lead  to  a  more  precise  mathematical 
representation  of  the  system  specifications  and  ultimately  to  an  executable  model.  This  executable 
Refine  model  could  be  used  to  assist  organization  leaders  in  evaluating  their  organizations.  While 
more  work  and  further  research  should  be  accomplished,  this  research  has  shown  that  formal  meth¬ 
ods  can  be  effectively  applied  to  problems  in  an  AF  organization  as  well  as  other  organizations 
outside  the  AF.  These  results  and  the  domain  model  developed  through  this  research  can  continue 
to  be  used  in  increasing  the  mission  effectiveness  and  readiness  of  the  AF. 
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Appendix  A.  Refine  Code 


!!  in-package ("RU") 
!!  in-grammar ( ’user) 

#1  I 


--  Object  Name:  Assigned 

—  Specification  Date:  09/12/95 

—  Filename:  assigned. re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Based  on:  Assigned  (950510) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  association  assigned 
Each  instance  represents  a  tool- job  link. 

—  History: 

—  09/12/95  (Hibdon) :  original  design. 


!  I# 


*/,'/,  Define  class  structure: 

var  Assigned:  object-class  subtype-of  user-object 
var  tassigned:  map(Assigned,  Tool)  =  {||} 
var  jassigned:  map  (Assigned,  Job)  =  -Cl  1} 

*/,'/,  Define  class  methods: 

function  NewAssignedO  :  Assigned  = 
make-object ( ’Assigned) 

function  ZapAssigned(a:  Assigned)  = 
erase-object (a) 

function  InitAssigned(a:  Assigned)  = 

NIL 

function  ShowAssigned(a:  Assigned)  = 
format  (TRUE,  M~\\pp\\  ~'/.M,  a) 

function  SetAssigned(a:  Assigned,  tl:  Tool,  j:  Job)  = 
TRUE  — >  (tassigned(a)  =  tl  &  jassigned(a)  =  j) 

function  GetTAssigned(a:  Assigned):  Tool  = 
tassigned(a) 

function  Get JAssigned(a:  Assigned):  Job  = 
jassigned(a) 


•///.- 


End  of  Assigned 


! !  in-package (“RU") 
!!  in-grammar ( ’user) 

#1  I 


—  Object  Name:  AssignedSet 

—  Specification  Date:  09/12/95 

—  Filename:  assignedset .re 

—  Specified  by:  Hibdon 

—  Based  on:  Assigned  (920510) 
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—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon) :  original  design. 


I  I# 

7,7.  Define  base  sets  (types): 

7.7.  Define  class  structure: 

var  AssignedSet:  object-class  subtype-of  Container 

'/,*/,  Define  class  methods: 

function  NewAssignedSet ()  :  AssignedSet  = 

make-object ( AssignedSet) 

function  InitAssignedSet (as :  AssignedSet)  = 

Init Container (as) 

function  ZapAssignedSet (as :  AssignedSet)  = 
erase-object (as) 

function  ShowAssignedSet (as :  AssignedSet)  = 
format  (TRUE,  "~\\pp\\  ~7." ,  as) 

function  ListAssignedSet (as :  AssignedSet)  = 
enumerate  aset  over  range (contents (as) )  do 
format  (TRUE,  M~\\pp\\  "7,",  aset) 

function  InAssignedSet (as :  AssignedSet,  j:  Job):  Boolean  = 

ex(asl :  assigned) (asl  in  contents (as)  &  Get JAssigned(asl)  =  j) 

7.7.  - End  of  AssignedSet  - 


!!  in-package ("RU") 

! !  in-grammar ( * us er ) 

#11 


—  Object  Name:  Assignment 

—  Specification  Date:  09/05/95 

—  Filename:  assignment . re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Must  compile  and  load  Faculty,  Student. 

—  Based  on:  Assignment  (950516) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  association  assignment 
Each  instance  represents  a  worker- job  link. 

—  History: 

—  09/05/95  (Hibdon):  original  design. 


II# 

7.7.  Define  class  structure: 

var  Assignment:  object-class  subtype-of  user-object 
var  wassignment:  map (Assignment ,  Worker)  =  {11} 
var  jassignment:  map (Assignment ,  Job)  =  {||} 

7.7.  Define  class  methods: 

function  NewAssignment ()  :  Assignment  = 
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make-object ( ’Assignment) 

function  ZapAssignment (p :  Assignment)  = 
erase-object (p) 

function  InitAss ignment (p:  Assignment)  = 

NIL 

function  ShowAssignment(p:  Assignment)  = 
format  (TRUE,  "~\\pp\\  "T\  p) 

function  SetAssignment (as :  Assignment,  w:  Worker,  j:  Job)  - 
TRUE  — >  (wassignment (as)  =  w  &  j assignment (as)  =  j) 

TL  Might  add  ( j ,  w)  in  qualif ied_f or 

function  SetAssignment (as :  Assignment,  w:  Worker,  j:  Job)  = 

wafsc(w)  in  jafsc_set(j)  — >  (wassignment (as)  =  w  &  j assignment (as)  =  j) 

function  GetWAssignment (as :  Assignment):  Worker  = 
was  s ignment ( as ) 

function  Get JAss ignment (as :  Assignment):  Job  = 
j ass ignment (as) 


•/.*/.- 


End  of  Assignment 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  AssignmentSet 

—  Specification  Date:  09/12/95 

—  Filename:  ass ignment set .re 

—  Specified  by:  Hibdon 

—  Based  on:  Assignment  (950516) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


I  I# 

7,7,  Define  base  sets  (types): 

'/,*/,  Define  class  structure: 

var  AssignmentSet:  object-class  subtype-of  Container 

7,*/,  Define  class  methods: 

function  NewAs s ignment S et ()  :  AssignmentSet  = 

make-object ( ’AssignmentSet) 

function  InitAs s ignment Set (as :  AssignmentSet)  = 
InitContainer (as) 

function  ZapAssignment Set (as :  AssignmentSet)  = 
erase-obj  ect(as) 

function  ShowA ss ignment Set (as :  AssignmentSet)  = 
format  (TRUE,  "~\\pp\\  "T\  as) 

function  Li stAss ignment Set (as :  AssignmentSet)  = 
enumerate  aset  over  range (contents (as) )  do 
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format  (TRUE,  ""WppW  *7.",  aset) 

function  GetAssignment (as :  Assignment Set ,  j:  Job):  Assignment  = 

arb({ass  |  (ass:  Assignment)  (ass  in  contents (as)  &  jname(Get JAssignment (ass) ) 

function  JoblnAssignmentSet (as :  Assignment Set ,  j:  Job):  Boolean  = 
ex(asl:  assignment) (as 1  in  contents(as)  &  Get JAssignment (asl)  =  j) 

7.7. - End  of  Assignment  Set  - 


!!  in-package  ("RU") 
!!  in-grammar ( ’user) 


#11 


—  Object  Name:  Container 

—  Specification  Date:  09/04/95 

—  Filename:  container. re 

—  Specified  by:  Hartrum 

—  Based  on:  Container 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/04/95  (Hartrum):  original  design. 

—  09/11/95  (Hibdon) :  Added  GetNext . 


I  I# 

7,7.  Define  base  sets  (types): 

7.7.  Define  class  structure: 

var  Container:  object-class  subtype-of  user-object 
var  cont_name:  map (Container,  string)  =  {111 
var  contents:  map  (Container,  seq(object))  =  -CM> 
var  cont_index:  map (Container ,  integer)  =  {||> 

7.7,  Define  class  methods: 

function  NewContainer ()  :  Container  = 
make-obj  ect ( *  Container) 

function  InitContainer (cont :  Container)  = 

TRUE  — >  cont.name (cont)  =  MM  &  contents (cont)  =  []  & 
cont_index(cont)  =  0 

function  ZapContainer (cont :  Container)  = 
eras e-obj ect (cont) 

function  ShowContainer (cont :  Container)  = 
format  (TRUE,  "~\\pp\\  "7.'\  cont) 

function  SetContName(cont :  Container,  cname :  string)  = 

TRUE  — >  cont _name( cont)  =  cname 

function  GetContName(cont :  Container):  string  = 
cont_name (cont) 

function  AddItem(cont :  Container,  item:  object)  = 

oldcont*  *  contents (cont)  — >  contents (cont)  =  append (oldcont* ,  item) 

function  Remove It em( cont :  Container,  item:  object)  = 

i  in  domain (contents (cont ) )  &  oldcont*  =  contents (cont)  & 

(contents (cont) ) (i)  =  item  — >  contents (cont)  =  delete(oldcont* ,  i) 

function  GetFirst (cont :  Container):  object  = 


jname(j ))}) 
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size (contents (cont))  >  0  — >  cont_index(cont)  =  1; 
(contents (cont) ) (1) 

function  GetNext (cont :  Container,  item:  object):  object  = 
Let  (tempindex:  integer  =  1) 

i  in  domain (contents (cont) )  &  (contents (cont) ) (i)  =  item 
tempindex  <-  (i  +  1) ; 

(contents (cont) ) (tempindex) 

*/.'/. - End  of  Container - 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  Job 

—  Specification  Date:  08/28/95 

—  Filename:  job. re 

—  Specified  by:  Hibdon 

—  Based  on:  Job  (950501) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  08/28/95  (Hibdon):  original  design. 


II# 

*/,*/,  Define  base  sets  (types): 

constant  AFSCS  :  set (string)  =  {  M33S3B\  "33S3CM} 

constant  J0B_STATUS  :  set (symbol)  =  {  ’ready,  ’waiting,  ’in-process,  ’finished} 

constant  DATA  :  set(symbol)  =  {  ’i0,  ’il,  ’i2,  ’i3,  ’i4,  ’i5,  ’i6,  ’ i7 ,  ’i8, 
’i9,  ’ilO,  ’ol,  ’o2 ,  ’ o3 ,  ’o4,  ’o5,  ’06,  ’o7,  ’08,  ’o9,  ’olO} 

var  tempjtime:  integer  =  0 

*/,*/,  Define  class  structure: 

var  Job:  object-class  subtype-of  user-object 
var  jname:  map(Job,  string)  =  {||> 
var  jpriority:  map(Job,  integer)  -  -C I  I > 
var  jafsc_set:  map(Job,  set(string))  =  -CM} 
var  jcomplexity:  map(Job,  integer)  =  -Cll} 
var  jskill_level :  map(Job,  integer)  =  -Cl!} 
var  jstatus:  map(Job,  symbol)  =  {11} 
var  jinputs:  map(Job,  set(symbol))  =  -CM} 
var  joutputs:  map(Job,  set(symbol))  =  -CM} 
var  javerage_time :  map(Job,  integer)  =  {||} 
var  jbest_time:  map(Job,  integer)  =  -CM} 
var  jworst_time:  map(Job,  integer)  =  -CM} 
var  j automat ed_t ime :  map(Job,  integer)  =  {M} 
var  javerage_accuracy :  map(Job,  integer)  =  -CM} 
var  jbest.accuracy :  map(Job,  integer)  =  {11} 
var  jworst_accuracy :  map(Job,  integer)  =  {11} 
var  jpercent.complete :  map(Job,  real)  =  {11} 
var  jstart.time:  map(Job,  integer)  =  { || } 
var  jend_time:  map(Job,  integer)  =  {11} 
var  jaccuracy:  map(Job,  integer)  =  {11} 
var  jtime:  map(Job,  integer)  =  {M} 

*/,'/,  Define  class  methods: 

function  NewJobO  :  Job  = 
make-object ( ’ Job) 

function  ZapJob( j :  Job)  = 
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erase-object (j) 


function  ShowJobC j :  Job)  = 

format  (TRUE,  "  Job  name:  "S"*/,  Job  priority:  ~S"'/,  Afsc.set:  ~S"'/.  complexity:  ~d"’/. 
skill_level:  "d"’/t  status:  "s "*/,  inputs:  "s"'/,  outputs:  "s"*/(  average.time :  "d"'/. 
best  .time:  "d~*/.  worst.time:  ~d"*/,  automated,  time :  "d~‘/,  average.accuracy :  "d"'/. 
best.accuracy :  "d ”7  worst.accuracy :  "d"'/,  percent. complete :  "d"'/,  start. time: 
's'1/,  end.time:  "s"*/,  accuracy:  "s"‘/»  time:  "d"*/,"*/,"*/," ,  jname(j),  jpriorityC j ) , 
jaf sc.set (j) ,  jcomplexityC j) ,  j skill.levelC j ) ,  jstatus(j),  jinputs(j), 
joutputs(j),  j average. t ime (j ) ,  jbest.timeCj ) ,  jworst.timeC j ) , 
jautomated.time(j) ,  j average.accuracy ( j ) ,  jbest.accuracy( j ) , 
j worst.accuracy (j ) ,  jpercent.complete(j) ,  jstart.time(j) ,  jend_time( j ) , 
jaccuracy(j) ,  jtime(j)) 

function  Setjname(j :  Job,  n:  string)  = 

TRUE  — >  jname(j)  =  n 

function  GetjnameCj:  Job):  string  = 
jname( j) 

function  Set jpriorityC j :  Job,  p:  integer)  = 

(p  >=  0)  k  (p  <=  100)  — >  jpriority(j)  =  p; 

(p  <  0)  OR  (p  >  100)  — >  ( jpriorityC j)  =  undefined) 

'/.  format  (TRUE,  ""‘/.priority  out  of  range  "*/.")) 


function  Get jpriorityC j :  Job) :  integer  = 
jpriorityCj ) 

function  Set jaf sc.set (j :  Job,  a:  set(string))  = 

TRUE  — >  jafsc.set(j)  =  a 

function  Get jaf sc.set (j :  Job):  set(string)  = 
jaf sc.setCj ) 

function  Set j complexity (j :  Job,  c:  integer)  = 

(c  >=  0)  &  (c  <=  100)  — >  j  complexity (j )  =  c; 

(c  <  0)  k  (c  >  100)  — >  jcomplexity(j)  =  undefined 

function  Get j complexity (j :  Job):  integer  = 
jcomplexity ( j) 

function  Set j skill.levelC j :  Job,  s:  integer)  = 

(s  >=  1)  &  (s  <=  9)  — >  j  skill.levelC j )  =  s; 

(s  <  1)  OR  (s  >  9)  — >  j skill.levelC j)  =  undefined 

function  Get j skill.levelC j :  Job):  integer  = 
jskill.level(j) 

function  Set j status (j :  Job,  s:  symbol)  = 

s  "in  JOB. STATUS  — >  jstatus(j)  <-  undefined; 
s  in  J0B.STATUS  — >  j status (j)  =  s 
'/.(s  "=  ’finished)  — >  (pc  <  100) 

function  Get jstatus ( j :  Job):  symbol  = 
jstatus(j) 

function  Set j inputs (j :  Job,  i:  set(symbol)  )  = 

TRUE  — >  jinputs(j)  -  i 

function  SetjlOCj:  Job,  i:  set(symbol),  o:  set(symbol))  = 

(i  intersect  o  =  {>)  — >  (jinputs(j)  =  i  &  joutputs(j)  =  o) 

function  Get j inputs (j :  Job):  set(symbol)  = 
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jinputs(j) 

function  Set joutputs( j :  Job,  o:  set (symbol))  = 

TRUE  — >  joutputs(j)  =  o 

function  Get joutputs(j :  Job):  set(symbol)  = 
j outputs (j ) 

function  Set javerage_time( j :  Job,  at:  integer  )  = 

TRUE  — >  javerage_time( j )  =  at 

function  Get javerage_time( j :  Job) :  integer  = 
j  average_time ( j ) 

function  Set jbest.time ( j :  Job,  bt :  integer  )  - 
TRUE  — >  jbest_time( j)  =  bt 

function  Get jbest.time ( j :  Job):  integer  = 
jbest_time( j ) 

function  Set jworst_time( j :  Job,  wt:  integer  )  = 

TRUE  — >  jworst_time(j)  =  wt 

function  Get jworst_time( j :  Job):  integer  = 
jworst_time( j ) 

function  Set j automat ed_time( j :  Job,  at:  integer  )  = 

TRUE  — >  jautomated_time(j)  =  at 

function  Get jautomated_time( j :  Job):  integer  = 
j automated. time ( j) 

function  Set j average. accuracy ( j :  Job,  aa:  integer  )  = 

TRUE  — >  javerage.accuracy(j)  =  aa 

function  Get javerage_accuracy ( j :  Job):  integer  = 
j  average.accuracy ( j ) 

function  Set jbest_accuracy ( j :  Job,  ba:  integer  )  = 

TRUE  — >  jbest_accuracy( j )  =  ba 

function  Get jbest_accuracy( j :  Job):  integer  = 
jbest .accuracy ( j ) 

function  Set jworst_accuracy( j :  Job,  wa:  integer  )  = 

TRUE  — >  jworst.accuracy(j)  =  wa 

function  Get jworst.accuracy ( j :  Job) :  integer  = 
jworst.accuracy (j ) 

function  Set jpercent_complete(j :  Job,  pc:  real  )  = 

(pc  >=  0.0)  &  (pc  <=  1.0)  — >  (jpercent.complete(j)  =  pc); 
(pc  =  1.0)  — >  (jstatus(j)  =  ’finished); 

(pc  >  0.0)  &  (pc  <  1.0)  — >  (jstatus(j)  =  ’in-process); 

(pc  =  0.0)  — >  (jstatus(j)  =  ’waiting) 

function  Get jpercent_complete( j :  Job):  real  = 
jpercent_complete( j) 

function  Set jst art.time ( j :  Job,  st:  integer  )  = 

TRUE  — >  j start _t ime( j )  =  st 

function  Get j start_time( j :  Job):  integer  = 
jstart.time ( j ) 
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function  Set jend_time( j :  Job,  et:  integer)  = 

(et  >  j start_time ( j ) )  — >  ( ( j end_time ( j )  =  et)  & 

(tempjtime  =  et  -  j start_time ( j ) ) ) ; 

(tempjtime  <=  jworst_time( j ) )  &  (tempjtime  >=  j automat ed^time( j ) ) 
jtime(j)  =  tempjtime; 

(et  <=  j start_time ( j ) )  — >  (j end_time(j )  =  undefined) 

function  Get jend_time( j :  Job):  integer  = 
jend_time ( j ) 

function  Set jaccuracy( j :  Job,  a: integer  )  = 

TRUE  — >  jac curacy (j)  =  a 

function  Get j accuracy ( j :  Job):  integer  = 
j accuracy (j ) 

‘/.function  Setjtime(j:  Job)  = 

'/.  TRUE  —  >  j  time  ( j)  =  jend_time(j)  -  jstart_time(j ) 

function  Getjtime(j:  Job):  integer  = 
jtime(j) 


u- 


End  of  Job 


!!  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  JobSet 

—  Specification  Date:  09/06/95 

—  Filename:  jobsetl.re 

—  Specified  by:  Hartrum 

—  Dependencies : 

Depends  on  Container. 

—  Based  on:  JobSet  (920501a) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/06/95  (Hibdon) :  original  design. 


II# 


'/,*/,  Define  base  sets  (types)  : 

'/,'/,  Define  class  structure: 

var  JobSet:  object-class  subtype-of  Container 
var  jobsetuse:  map(JobSet,  string)  =  {||> 

'/,'/.  Define  class  methods: 
function  NewJobSetO  :  JobSet  = 
make-object ( ’ JobSet) 

function  Xnit JobSet (js :  JobSet)  = 

Init Container (js) 

function  ZapJobSet ( j s :  JobSet)  = 
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erase-object ( js) 

function  ShowJobSet(js :  JobSet)  = 
format  (TRUE,  "~\\pp\\  ~7.” ,  js) 

function  Set JobSetUse( j s :  JobSet,  j_use:  string)  = 
TRUE  — >  jobsetuse(js)  =  j_use 

function  Get JobSetUse ( j s :  JobSet):  string  = 
jobsetuse(js) 

function  GetAllJob( j s :  JobSet):  set(Job)  = 
range (contents (js)) 

function  List JobSet (js :  JobSet)  = 

enumerate  j  over  range (contents (js))  do 
format  (TRUE,  ”~\\pp\\  '7,",  GetjName(j)) 

function  Calculate JobTime( jl :  Job)= 

TRUE  — >  jtime(jl)  =  75 

function  Set JobTimes ( js :  set(Job))  = 
j  in  js  — >  Calculate JobTime (j ) 


7.7.- 


End  of  JobSet 


! !  in-package ("RU") 
!!  in-grammar ( * user) 
#11 


—  Object  Name:  ManningPlan 

—  Specification  Date:  09/11/95 

—  Filename:  manning. re 

—  Specified  by:  Hibdon 

—  Based  on:  ManningPlan  (950506a) 

—  Design  Transforms  and  Rationale: 

—  History: 

--  09/11/95  (Hibdon):  original  design. 


I  I# 

7.7.  Define  base  sets  (types) : 

7.7.  Define  class  structure: 

var  ManningPlan:  object-class  subtype-of  user-object 

var  positions:  map (ManningPlan,  set (Position) )  =  11  II 

7.7.  Define  class  methods: 

function  NewManningPlanO  :  ManningPlan  = 
make-obj  ect ( 1 ManningPlan) 

function  ZapManningPlan(mp:  ManningPlan)  = 
erase-object (mp) 

function  ShowManningPlan(mp :  ManningPlan)  = 
format(TRUE,  "ManningPlan  "7.  Positions:  ~S~7.~7.~7."  »  positions  (mp) ) ; 
format  (TRUE,  "~\\pp\\  "7.",  mp) 

function  Setpositions(mp:  ManningPlan,  ps:  set (Position) )  = 

positions*  =  positions (mp)  — >  positions (mp)  =  positions*  union  ps 
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7.7. 


End  of  ToolSet 


!  !  in-package  ( 11 RU") 

! !  in-grammar ( ’user) 

#11 


—  Object  Name:  Occupy 

—  Specification  Date:  09/12/95 

—  Filename:  occupy. re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Based  on:  Occupy  (950514) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  occupy 

Each  instance  represents  a  position-worker  link. 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


I  I# 

7.7.  Define  class  structure: 

var  Occupy:  object-class  subtype-of  user-object 
var  poccupy:  map(0ccupy,  Position)  =  {111 
var  woccupy:  map(0ccupy,  Worker)  =  {j|} 

7.7.  Define  class  methods: 
function  NewOccupyO  :  Occupy  = 

make-obj  ect ( *  Occupy) 

function  ZapOccupy(o:  Occupy)  = 
erase-object (o) 

function  InitOccupy(o :  Occupy)  = 

NIL 

function  ShowOccupy (o :  Occupy)  = 
format  (TRUE,  "~\\pp\\  "7." ,  o) 

function  SetOccupy(o:  Occupy,  p:  Position,  w:  Worker)  = 
TRUE  — >  (poccupy (o)  =  p  &  woccupy (o)  =  w) 

function  GetPOccupy (o :  Occupy):  Position  = 
poccupy(o) 

function  GetWOccupy (o :  Occupy):  Worker  = 
woccupy(o) 


7.7.- 


End  of  Occupy 


!!  in-package ("RU") 
!!  in-grammar ( ’user) 

#1  I 


—  Object  Name:  OccupySet 

—  Specification  Date:  09/12/95 

—  Filename:  occupyset. re 

—  Specified  by:  Hibdon 

—  Based  on:  Occupy  (950514) 

—  Design  Transforms  and  Rationale: 
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—  History: 

—  09/12/95  (Hibdon) :  original  design. 


M# 


7,7.  Define  base  sets  (types): 

'/,'/,  Define  class  structure: 

var  OccupySet:  object-class  subtype-of  Container 

7.7.  Define  class  methods: 

function  NewOccupySet ()  :  OccupySet  = 
make-object ( ’  OccupySet) 

function  InitOccupySet (os :  OccupySet)  = 

InitContainer(os) 

function  ZapOccupySet (os :  OccupySet)  = 
erase-object(os) 

function  ShowOccupySet (os :  OccupySet)  = 
format (TRUE,  n“\\pp\\  ~7." ,  os) 

function  ListOccupySet (os :  OccupySet)  = 

enumerate  osset  over  range (contents (os) )  do 
format  (TRUE,  M~\\pp\\  osset) 

7,'/,  Correctly  occupied  positions  based  on  afsc  only. 

function  GetCorrectlyOccupiedPositions(os :  OccupySet):  Set(Occupy)  = 

{occ  |  (occ:  Occupy)  (occ  in  contents(os)  &  posaf sc(GetPOccupy(occ) )  =  wafsc (GetWOccupy(occ) ) )} 

7.7.  Correctly  occupied  positions  based  on  afsc  and  skill  level. 

function  GetCorrectly0ccupiedPositions2(os :  OccupySet):  Set(Occupy)  = 

{occ  1  (occ:  Occupy)  (occ  in  contents(os)  &  posaf sc(GetPOccupy(occ) )  = 
waf sc(GetWOccupy(occ) )  &  wskill_level(GetWOccupy(occ) )  >= 
posskill_level(GetPOccupy (occ) ) )} 

7.7.  - End  of  OccupySet  - 


!!  in-package (nRUM) 
!!  in-grammar ( ’ user) 

#1  I 


—  Object  Name:  Organization 

—  Specification  Date:  09/08/95 

—  Filename:  org.re 

--  Specified  by:  Hibdon 

—  Based  on:  Organization  (950507) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/08/95  (Hibdon):  original  design. 


II# 

7.7.  Define  base  sets  (types): 

constant  J0B_STATUS  :  set (symbol)  =  {  ’ready,  ’waiting,  ’in-process,  ’finished} 
constant  DATA  :  set(symbol)  =  {  ’il,  ’i2,  ’i3,  ’oi,  ’o2,  ’o3} 
var  temptime:  integer  =  0 
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*/,'/,  Define  class  structure: 

var  Organization:  object-class  subtype-of  user-object 

7.7.  Attributes 

var  oname:  map (Organization,  string)  -  {11} 

var  unit_ef f ectiveness :  map (Organization,  integer)  ={||} 

var  unit_eff iciency :  map (Organization,  integer)  =  {|l> 

var  unit_readiness :  map (Organization,  real)  =  {||> 

var  org-toolset:  map (Organization,  ToolSet)  =  {11} 

var  org-workforce :  map (Organization,  Workforce)  =  {| l> 

var  org-projectset :  map (Organization,  Set (Proj ect) )  =  {|  1} 

var  org-taskset:  map (Organization,  Set(Task))  =  {11} 

var  org-jobset:  map (Organization,  Set(Job))  =  { I  I } 

7.7.  Associations 

var  org-using:  map (Organization,  usingset)  =  {11} 

var  org-qualif ied_on:  map (Organization,  qualif ied_onset)  =  {11} 

var  org-assigned:  map (Organization,  assignedset)  =  {||} 

var  org-supports :  map (Organization,  supportsset)  =  {||} 

var  org-assignment :  map (Organization,  assignment set)  =  {||} 

var  org-qualif ied_f or :  map (Organization,  qualif ied_forset)  =  {| 1} 

var  org-precedes :  map (Organization,  precedesset)  =  {||} 

var  org-occupy:  map (Organization,  occupyset)  =  {11} 

Temp  Globals 

var  tempusing:  Using  =  undefined 

var  tempqualif iedon :  Qualif ied_0n  =  undefined 

var  tempoccupy:  Occupy  =  undefined 

var  tempassigned:  Assigned  =  undefined 

var  tempsupports :  Supports  =  undefined 

var  tempqualif iedf or :  Qualif ied_For  =  undefined 

var  temp assignment :  Assignment  =  undefined 

var  tempprecedes :  Precedes  =  undefined 

var  tempworker:  Worker  “  undefined 

var  temptool:  Tool  =  undefined 

var  temptime*:  integer  =  0 

var  temppossiblequalif iedon :  Qualif ied_0n  =  undefined 

var  org-possiblequalif ied_onset :  Qualif ied„0nSet  =  undefined 

7.7.  Define  class  methods: 

function  NewOrganizationQ  :  Organization  = 
make-object ( *  Organization) 

function  ZapOrganization(ol :  Organization)  = 
erase-obj  ect (ol) 

function  InitOrg(ol:  Organization)  = 

7.7.  Initialize  attributes 

oname (ol)  <-  "Air  Force  Organization"; 
unit.ef f ectiveness(ol)  <-  0; 
unit_eff iciency(ol)  <-  0; 
unit_readiness(ol)  <-  0.0; 

7.7.  Initialize  Association  sets 
org-using(ol)  <-  NewUsingSet () ; 

InitUsingSet (org-using(ol ) ) ; 

org-qualif ied_on(ol)  <-  NewQualif ied_0nSet() ; 

InitQualif ied_0nSet (org-qualif ied_on(ol) ) ; 
org-possiblequalif ied_onset  <-  NewQualif ied_0nSet () ; 

InitQualif ied_ OnSet (org-possiblequalif ied_onset) ; 

7.  org-qualif ied_on(ol)  <-  {}; 

org-assigned(ol)  <-  NewAssignedSet () ; 

InitAssignedSet (org-assigned(ol) ) ; 
org-supports (ol)  <-  NewSupportsSet () ; 

InitSupportsSet (org-supports (ol) ) ; 
org-assignment (ol)  <-  NewAssignmentSet () ; 

InitAss ignment Set (org-assignment (ol) ) ; 
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org-qualif ied_f or(ol)  <-  NewQualif ied.ForSet () ; 

InitQualified.ForSet (org-qualif ied_f or (ol) ) ; 

org-precedes (ol)  <-  NewPrecedesSet () ; 

InitPrecedesSet (org-precedes (ol) ) ; 
org-occupy(ol)  <-  NewOccupySet () ; 

Init Occupy Set (org-occupy (ol) ) ; 

7,'/.  Initialize  Project,  Task  and  Job  sets,  etc 

org-projectset (ol)  <-  {>; 
org-taskset (ol)  <-  {}; 
org-jobset(ol)  <-  {}; 
org-workf orce(ol)  <-  NewWorkf orceQ ; 

InitWorkf orce (org-workf orce (ol) ) ; 
org-toolset (ol)  <-  NewToolSet () ; 

InitToolSet (org-toolset (ol) ) 

function  AddWorkertowf (ol :  Organization,  wl :  Worker) = 

TRUE  — >  (tempworker  <-  NewWorkerO; 

Setwname (tempworker ,  wname(wl)); 

Setwaf sc (tempworker,  wafsc(wl)); 

Setwskill_level(tempworker ,  wskill.level(wl)) ; 

Setwavailability (tempworker ,  wavailability(wl)) ; 

Setwexperience (tempworker ,  wexperience (wl) ) ; 

Setweducation(tempworker ,  weducation(wl) ) ; 

Setwaptitude (tempworker,  waptitude(vl)) ; 

AddItem(org-workf orce(ol) ,  tempworker)) 

function  AddTooltots(ol :  Organization,  tl:  Tool)= 

TRUE  — >  (temptool  <-  NewToolO; 

Settoolname(temptool,  toolnaine(tl) )  ; 

Settoolstatus (temptool ,  toolstatus (tl) ) ; 

Set tool avail ability (temptool ,  toolavailability (tl) ) ; 

Settoolafsc_set(temptool,  toolaf sc„set (tl) ) ; 

Settoolskill_level(temptool,  toolskill_level(tl) ) ; 

Addltem( org-toolset (ol) ,  temptool) ) 

7,7,  Functions  to  add  members  to  association  sets 
function  AddUsing(ol:  Organization,  tl:  Tool,  wl:  Worker)= 

TRUE  — >  (tempusing  <-  NewUsingO; 

SetUsing(tempusing,  tl,  wl) ; 

Addlt  em ( org-us ing ( o 1 ) ,  t empus ing) ) 

function  AddQualif ied_0n(ol :  Organization,  tl:  Tool,  wl:  Worker)= 

TRUE  -->  (tempqualif iedon  <-  NewQualif ied_0n() ; 

S et Qualified. On (tempqualifiedon,  tl,  wl) ; 

AddItem(org-qualif ied_on(ol) ,  tempqualif iedon) ) 

function  AddPossibleQualif ied_0n(ol :  Organization,  tl:  Tool,  wl:  Worker)= 

TRUE  — >  (temppossibl equal if iedon  <-  NewQualif ied_0n() ; 

SetQualif ied_On(temppossiblequalif iedon,  tl,  wl) ; 

AddI t em ( or g-po ssiblequalified. onset ,  temppossiblequalif iedon) ) 

function  AddOccupy(ol :  Organization,  pi:  Position,  wl:  Worker)= 

TRUE  — >  (tempoccupy<-  NewOccupyO; 

SetOccupy(tempoccupy ,  pi,  wl); 

Addltem( org-occupy (ol) ,  tempoccupy)) 

function  AddAssigned(ol :  Organization,  tl:  Tool,  jl:  Job)= 

TRUE  — >  (tempassigned  <-  NewAssignedO ; 

Se t As signed(tempas signed,  tl,  jl); 

AddItem(org-assigned(ol) ,  tempassigned)) 

function  AddSupports (ol :  Organization,  tl:  Tool,  jl:  Job,  timel:  integer,  percentl:  integer)= 


118 


TRUE  — >  (tempsupports<-  NewSupports () ; 

SetSupports(tempsupports ,  ti,  jl,  timel,  percentl); 

AddItem(org-supports(ol) ,  tempsupports) ) 

function  AddQualif ied.For (ol :  Organization,  wl :  Worker,  jl:  Job,  accuracyl:  integer,  timel:  integer)= 
TRUE  — >  (tempqualif iedf or<-  NewQualif ied_For() ; 

SetQualif ied_For (tempqualif iedf or ,  wl,  jl,  accuracyl,  timel); 

AddItem(org-qualif ied_f or (ol) ,  tempqualif iedf or) ) 

function  AddQualif ied_For2(ol :  Organization,  wl :  Worker,  jl:  Job)= 

TRUE  — >  (tempqualif iedf or <-  NewQualif ied_For() ; 

SetQualif ied_For4a(tempqualif iedf or ,  wl ,  jl); 

AddItem(org-qualif ied_f or (ol) ,  tempqualif iedf or) ) 

function  AddAssignment (ol :  Organization,  wl :  Worker,  jl:  Job)= 

TRUE  -->  (tempassignment  <-  NewAssignment () ; 

Set Assignment (temp assignment ,  wl,  jl); 

AddItem(org-assignment (ol) ,  tempassignment)) 

function  AddAssignment (ol :  Organization,  wl:  Worker,  jl:  Job)= 

TRUE  — >  (tempassignment  <-  NewAssignment () ; 

Set Assignment (tempassignment ,  wl,  jl); 

AddItem(org- assignment (ol) ,  tempassignment)) 

function  AddPrecedes (ol :  Organization,  jl:  Job,  j2:  Job)= 

First  add  the  new  member 
TRUE  — >  (tempprecedes  <-  NewPrecedes () ; 

SetPrecedes (tempprecedes ,  jl,  j2,  ol); 

AddItem(org-precedes (ol) ,  tempprecedes)) ; 

!'l  Now  check  for  intersection  and  remove  if  necessary 

j output s ( j 1 )  intersect  jinputs(j2)  =  {>  — >  RemoveItem(org-precedes (ol) ,  tempprecedes) 


'/,*/,  This  function  will  not  display  undefined  attributes 

function  ShowOrg(ol:  Organization)  = 
format  (TRUE,  "~\\pp\\‘7.M ,  ol) 

*///,  This  function  will  display  undefined  attributes 

function  ShowOrganization(ol :  Organization)  = 

format  (TRUE,  "  Organization  name:  ~S“7,  unit_ef  f  ectiveness :  ~d  "7, 
unit_ef  f  iciency :  ~d~'l  unit_readiness  :  "d”*/,  org-using:  "s"'/,  org-qualif ied_ on: 
~s~'/,  org-assigned:  "s"*/,  org-supports :  "s"'/,  org- assignment :  ~s~’/. 
org-qualif  ied_f  or :  “s org-precedes :  "s"'/,  org-occupy:  "s"'/,  org-jobset:  "s"'/, 
org-taskset:  "S"'/,  org-projectset :  "s 7, ,  oname(ol), 
unit_effectiveness(ol) ,  unit_eff iciency (ol) ,  unit_readiness(ol) , 
org-using(ol) ,  org-qualif ied_on(ol) ,  org-assigned(ol) ,  org-supports (ol) , 
org-assignment (ol) ,  org-qualif ied_f or (ol) ,  org-precedes (ol) ,  org-occupy (ol) , 
org-jobset (ol) ,  org-taskset (ol) ,  org-projectset (ol) ) 

function  Setoname(ol:  Organization,  n:  string)  = 

TRUE  — >  oname(ol)  =  n 

function  Getoname(ol:  Organization):  string  = 
oname(ol) 

*/,'/,  Checks  boundary  conditions 
Checks  boundary  conditions 

function  Setunit.eff ectiveness (ol :  Organization,  ue:  integer)  = 

(ue  >=  0)  &  (ue  <=  100)  — >  unit^eff ectiveness (ol)  =  ue; 

(ue  <  0)  OR  (ue  >  100)  — >  unit_eff ectiveness (ol)  =  -undefined 

function  Getunit_eff ectiveness (ol :  Organization):  integer  = 
unit.eff ectiveness (ol) 
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'/,*/,  Checks  boundary  conditions 

function  Setunit.eff iciency(ol :  Organization,  uef :  integer)  = 

(uef  >=  0)  &  (uef  <=  100)  — >  unit.eff iciency(ol)  =  uef; 

(uef  <  0)  OR  (uef  >  100)  — >  unit.eff iciency(ol)  =  undefined 

function  Getunit_effectiveness(ol :  Organization):  integer  = 
unit _ef feet iveness(ol) 

Sets  unit  readiness  manually 

function  Setunit_readinessl(ol :  Organization,  ur:  real)  = 

(ur  >=  0)  &  (ur  <=  100)  — >  unit. readiness (ol)  =  ur; 

(ur  <  0)  OR  (ur  >  100)  — >  unit .readiness (ol)  =  undefined 

7.7,  Calculates  unit  readiness  based  on  ToolSet  and  Workforce 
function  Setunit .readiness (ol :  Organization)  = 

TRUE  — >  unit .readiness (ol)  =  GetTool. Readiness (org-toolset (ol) )  +  GetForce_Readiness(org-workf orce(ol) ) 

function  Getunit.readiness (ol :  Organization):  real  = 
unit.readiness (ol) 

7,’/,  Calculates  all  of  the  time  attributes  for  jobs  in  the  organization’s  jobset 
based  on  the  worker-job  assignment  and  the  qualif ied.f or  association 
expect .time  attribute. 

function  CalculateTimes (ol :  Organization,  projl:  Project)= 
enumerate  p  over  range ( contents (org- assignment (ol) ) )  do 
j time ( Get J Assignment (p))  <- 

GetExpect_Time(GetQualif ied.For (org-qualif ied.f or (ol) ,  Get JAssignment (p) )) 

7.7,  Now  takes  into  account  the  tool- job  assigned  association  and  the  supports 
association  time  attribute 

function  CalculateTimes (ol :  Organization,  projl:  Project) = 
enumerate  p  over  range ( contents (org-assignment (ol) ) )  do 
j time (Get JAssignment (p) )  <- 

GetExpect.Time (GetQualif ied.For (org-qualif ied.f or (ol ) ,  Get JAssignment (p) ) ) 

-  suptime (GetSupports (org-supports (ol) ,  GetJAssignment (p) ) ) 

function  CalculateAccuracys(ol :  Organization,  projl:  Project)* 

fa(j)((j  in  org-jobset(ol)  &  JoblnAssignmentSet (org-assignment (ol) ,  j))  => 
jaccuracy(j)  <- 

GetExpect. Ac curacy (Get Qualif ied.For (org-qualif ied.f or (ol) ,  j ) ) ) 

7.7,  Calculates  all  of  the  accuracy  attributes  for  jobs  in  the  organization’s 
jobset  based  on  the  worker-job  assignment  and  the  qualif ied.f or  association 
expect.accuracy  attribute.  Also  takes  into  account  the  tool-job  assigned 
association  and  the  supports  association  percentage  attribute 

function  CalculateAccuracys(ol :  Organization,  projl:  Project)= 
enumerate  p  over  range (contents (org-assignment (ol) ) )  do 
j accuracy (Get JAssignment (p) )  <- 

GetExpect.Accuracy (GetQualif ied.For (org-qualif ied.f or (ol) ,  GetJAssignment (p))) 

+  percentage (GetSupports (org-supports (ol) ,  Get JAssignment (p) ) ) 

function  Setorg-projectset (ol :  Organization,  ps :  Set (Project) )= 

True  — >  org-projectset (ol)  <-  ps 

7,7,  Functions  to  find  and  assign  all  of  the  tasks  and  jobs  of  an  organization 
function  Getorg-taskset (ol :  Organization)* 

TRUE  — >  org-taskset (ol)  =  reduce(union,  {ptask.set (pi)  I 
(pi:  Project)  pi  in  org-projectset (ol)}) 

function  Getorg-jobset (ol :  Organization):  set(Job)  = 
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TRUE  — >  org-jobset (ol)  =  reduce (union,  {pjob.set (pi)  I 
(pi:  Project)  pi  in  org-projectset(ol)}) ; 
org-projectset (ol) 

function  Showorg-jobset (ol :  Organization^ 
enumerate  j  over  org-jobset (ol)  do 
format (TRUE,  M"\\pp\\  T' ,  j) 

7.'/. - End  of  Organization - 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 
#1 ! 


—  Object  Name:  Position 

—  Specification  Date:  08/28/95 

—  Filename:  position. re 

—  Specified  by:  Hibdon 

—  Based  on:  Position  (950506) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  08/28/95  (Hibdon):  original  design. 


I  I# 

7.7,  Define  base  sets  (types) : 

constant  AFSCS  :  set  (string)  =  {  "33S3B",  "33S3C\  "4921"} 

7.7.  Define  class  structure: 

var  Position:  object-class  subtype-of  user-object 
var  posnumber:  map(Position,  integer)  =  {11} 
var  posafsc:  map(Position,  string)  =  {11} 
var  posskill.level :  map(Position,  integer)  =  {11} 

7,7.  Define  class  methods: 

function  NewPositionQ  :  Position  = 
make-object( ’Position) 

function  ZapPosition(p :  Position)  = 
erase-object (p) 

function  ShowPosition(p :  Position)  = 

format  (TRUE,  "  Position  number:  ~d~7.  Afsc:  ~S~7.  skill_level:  ~d*7.*7.'7.~7.M , 
posnumber(p) ,  posafsc(p),  posskill_level(p) ) 

function  Setposnumber(p :  Position,  n:  integer)  = 

TRUE  — >  posnumber (p)  =  n 

function  Getposnumber (p :  Position):  integer  = 
posnumber (p) 

7,7.  Checks  if  afsc  is  valid 

function  Setposaf sc(p :  Position,  a:  string)  = 
a  in  AFSCS  — >  posafsc(p)  *  a; 
a  "in  AFSCS  — >  posafsc (p)  =  undefined 

function  Getposaf sc(p :  Position):  string  = 
posaf sc(p) 

7,7.  Checks  boundary  ranges 

function  Setposskill_level(p :  Position,  s:  integer)  = 
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(s  >=  1  &  s  <=  9)  — >  posskill.level(p)  =  s 

function  Getposskill_level(p:  Position):  integer  = 
posskill_level(p) 


•/:/.- 


End  of  Position 


!  !  in-package ("RU") 
!i  in-grammar ( 'user) 


#11 


—  Object  Name:  Precedes 

—  Specification  Date:  09/12/95 

—  Filename:  precedes. re 

—  Specified  by:  Hibdon 

—  Dependencies: 

Must  compile  and  load  Tool,  Worker. 

—  Based  on:  Precedes  (950517) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  precedes 
Each  instance  represents  a  Job-Job  link. 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


7.7.  Define  class  structure: 

var  Precedes:  object-class  subtype-of  user-object 
var  jlprecedes:  map(Precedes ,  Job)  =  {||} 
var  j2precedes:  map(Precedes ,  Job)  =  {113- 

7,7  Define  class  methods: 
function  NewPrecedes ()  :  Precedes  = 

make-obj  ect ( 'Precedes) 

function  ZapPrecedes (p :  Precedes)  = 
erase-object (p) 

function  InitPrecedes (p :  Precedes)  = 

NIL 

function  ShowPrecedes(p :  Precedes)  = 
format  (TRUE,  "~\\pp\\  ,  p) 

function  SetPrecedes (p :  Precedes,  jl:  Job,  j2:  Job)  = 

TRUE  — >  (jlprecedes (p)  =  jl  &  j2precedes(p)  =  j2) 

7,'/,  The  next  two  functions  display  incremental  development  of  the  same  function. 
If  compiled  as  follows,  the  last  function  will  be  the  one  recognized  and  used 
by  the  system. 

7.7.  Input  and  outputs  are  checked  as  well  as  start  and  stop  times, 
function  SetPrecedes (p :  Precedes,  jl:  Job,  j2:  Job)  = 

joutputs(jl)  intersect  j inputs (j2)  ~=  O  &  jend.time(jl)  <=  j start.time( j2) 

— >  (jlprecedes (p)  =  jl  &  j 2precedes (p)  =  j2) 

7,7.  Safety  check:  item  is  removed  if  intersect  is  empty. 

function  SetPrecedes(p :  Precedes,  jl:  Job,  j2:  Job,  ol:  Organization)  = 

(j outputs (jl)  intersect  j inputs (j 2)  O  &  jend.time ( j 1)  <=  j start .time (j 2) ) 

— >  (j lprecedes(p)  =  jl  &  j2precedes (p)  =  j2); 
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j output s ( j 1 )  intersect  j inputs (j 2)  =  {>  — >  RemoveItem(org-precedes (ol) ,  p) 

function  Get j IPrecedes (p :  Precedes):  Job  = 
jlprecedes(p) 

function  Get j 2Precedes (p:  Precedes):  Job  = 
j2precedes(p) 


*/:/.- 


End  of  Precedes 


;  ; 
i  j 

#1  I 


in-package ("RU") 
in-grammar ( ’ user) 


—  Object  Name:  PrecedesSet 

—  Specification  Date:  09/12/95 

—  Filename:  precedesset . re 

—  Specified  by:  Hibdon 

—  Based  on:  Precedes  (950517) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


II# 

7.7.  Define  base  sets  (types): 

7.7.  Define  class  structure: 

var  PrecedesSet :  object-class  subtype-of  Container 

Vi  Define  class  methods: 

function  NewPrecedesSet ()  :  PrecedesSet  - 
make-obj  ect ( 'Precedes Set) 

function  InitPrecedesSet (ps :  PrecedesSet)  = 

InitContainer(ps) 

function  ZapPrecedesSet (ps :  PrecedesSet)  = 
erase-object (ps) 

function  ShowPrecedesSet (ps :  PrecedesSet)  = 
format  (TRUE,  "“\\pp\\  ~7." ,  ps) 

7,  Might  want  to  do  it  this  way  instead  of  checking  in  SetPrecedes 

function  GetAllPrecedes (ps :  PrecedesSet):  Set (Precedes)  = 

{pre  |  (pre:  Precedes)  (pre  in  contents (ps)  &  (j outputs (Get JlPrecedes(pre) ) 
intersect  j inputs (Get J2Precedes (pre))  ~=  O)  &  jend_time(Get JlPrecedes (pre) ) 
<=  j  start_time (Get J2Pre cedes (pre) ) ) } 

/.function  GetAllPrecedes  (j  s  :  Set  (Job)):  Set  (Precedes)  = 

7,  {pre  |  (pre:  Precedes)  (pre  in  contents (ps)  &  ( j outputs (Get JlPrecedes (pre) ) 
intersect  j inputs (Get J2Precedes (pre) )  "=  {})  &  jend_time(Get JlPrecedes (pre) ) 
<=  j  start _time(GetJ2Precedes(pre) ) )} 

function  ListPrecedesSet (ps :  PrecedesSet)  = 
enumerate  pset  over  range (contents (ps))  do 
format  (TRUE,  ""WppW  ~7.M ,  pset) 

Vi - End  of  PrecedesSet  - 


!!  in-package ("RU") 
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!!  in-grammar ( ’user) 

#11 


—  Object  Name:  Project 

—  Specification  Date:  08/28/95 

—  Filename:  project. re 

—  Specified  by:  Hibdon 

—  Based  on:  Project  (950503) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  08/28/95  (Hibdon):  original  design. 


I  I# 

’/,'/,  Define  base  sets  (types): 

constant  JOB.STATUS  :  set (symbol)  =  {  ’ready,  ’waiting,  ’in-process,  ’finished} 
constant  DATA  :  set(symbol)  =  {  ’il,  ’i2,  ’i3,  ’ol,  ’o2,  ’o3} 
var  temptime:  integer  =  0 

’/,'/,  Define  class  structure: 

var  Project:  object-class  subtype-of  user-object 
var  pname :  map(Project,  string)  =  {11} 
var  ppriority:  map (Project,  integer)  =  {11} 
var  pstatus:  map(Project,  symbol)  =  { I  I } 
var  ptime_so_far :  map(Proj ect ,  real)  =  { I  I } 
var  pnumber.of .tasks :  map (Project,  integer)  =  { I  I } 
var  ptasks. complete:  map(Project,  integer)  =  {||} 
var  ppercent.complete :  map(Project,  real)  -  {||} 
var  pnumber.of .jobs :  map(Project,  integer)  =  {11} 
var  pj obs. complete :  map(Project,  integer)  =  { I  I } 
var  pstart_time:  map(Project,  integer)  =  { I  I } 
var  pend_time:  map(Project,  integer)  =  {11} 
var  pwall.time:  map(Project,  integer)  =  { I  I } 
var  ptotal.time:  map(Project,  real)  =  { I  I } 
var  paccuracy:  map(Project,  integer)  =  {11} 

*/,'/,  maps  from  an  object  to  a  set  of  objects  without  using  the  container. 

Could  have  made  new  objects  of  container  type  called  JobSet  and  TaskSet. 
var  ptask.set:  map(Project,  set(Task))  =  {11} 
var  pjob.set:  map(Project,  set(Job))  =  {11} 

*/,'/,  Define  class  methods: 
function  NewProjectO  :  Project  = 
make-object ( ’Project) 

function  ZapProject(pl :  Project)  = 
eras e-obj  ect (pi) 

function  ShowProject(pl :  Project)  = 

format  (TRUE,  "  Project  name:  ~S*7.  Project  priority:  "S"*/,  status:  ~s~'/. 
time.so.far:  ~d~*/.  number.of .tasks :  ~d“7,  tasks. complete : 

percent_complete  :  ~d~’/,  number_of  .jobs :  “d"*/,  jobs.complete :  “d~*/  start_time: 
“s*7,  end.time:  ~s*7,  wall_time:  "d"'/,  total.time:  ~d~'/.  accuracy:  “s"*/,  task.set: 

job.set:  *  s  ~*/t *! V7* "  ,  pname(pl),  ppriority(pl) ,  pstatus(pl), 
ptime.so.f ar(pl) ,  pnumber.of .tasks (pi) ,  ptasks_complete(pl) , 
ppercent.complete (pi) ,  pnumber.of .jobs (pi) ,  pjobs.complete (pi) , 
pstart.time(pl) ,  pend.time(pl) ,  pwall_time(pl) ,  ptotal.time (pi) , 
paccuracy (pi) ,  ptask.set (pi) ,  pjob.set (pi) ) 

function  Setpname (pi :  Project,  n:  string)  = 

TRUE  — >  pname (pi)  =  n 
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function  GetpnameCpl :  Project):  string  » 
pname(pl) 

*/,'/,  Checking  boundary  ranges 

function  Setppriority(pl :  Project,  p:  integer)  = 

(p  >=  0)  &  (p  <=  100)  -->  ppriority(pl)  =  p; 

(p  <  0)  OR  (p  >  100)  — >  (ppriority(pl)  =  undefined) 

function  Getppriority (pi :  Project):  integer  = 
ppriority (pi) 

function  Setpstatus (pi :  Project)  = 

fa(tl)((tl  in  ptask_set(pl)  &  tstatus(tl)  =  ’finished)  => 
pstatus(pl)  =  ’finished); 

fa(tl)((tl  in  ptask.set(pl)  &  tstatus(tl)  =  ’waiting)  => 
pstatus(pl)  =  ’waiting); 

f a(tl) ( (tl  in  ptask_set (pi)  &  tstatus(tl)  =  ’ready)  => 
pstatus(pl)  =  ’ready); 

ex(tl) (tl  in  ptask.set(pl)  &  tstatus(tl)  =  ’in-process)  => 
pstatus(pl)  <-  ’in-process 

*/,'/,  Retrieves  the  project  status  based  on  the  status  of  the  tasks  in  the 
project’s  taskset. 

function  Getpstatus (pi :  Project):  symbol  = 

f a(tl) ( (tl  in  ptask.set(pl)  &  tstatus(tl)  =  ’finished)  => 
pstatus(pl)  =  ’finished); 

f a(t 1) ( (tl  in  ptask_set (pi)  &  tstatus(tl)  =  ’waiting)  => 
pstatus(pl)  =  ’waiting); 

f a(tl) ( (tl  in  ptask.set(pl)  &  tstatus(tl)  =  ’ready)  => 
pstatus (pi)  =  ’ready); 

ex(tl) (tl  in  ptask_set(pl)  &  tstatus(tl)  =  ’in-process)  => 
pstatus (pi)  <-  ’in-process; 
pstatus (pi) 

U  Calculates  project’s  time  so  far  based  on  the  tasks 
function  Setptime.so.f ar(pl :  Project)  = 

Let  (temptask:  Task  =  arb({tl  I  (tl:  Task)  tl  in  ptask.set (pi)  & 
tstatus(tl)  =  ’ in-process}) ) 

TRUE  — >  ptime.so.f ar(pl)  <-  t start .time (temptask)  +  twall.time (temptask)  * 
tpercent. complete (temptask) 

function  Getptime_so_f ar (pi :  Project):  real  = 
ptime.so.f ar(pl) 

•/'/,  Project  percent  complete  based  on  the  amount  of  time  for  finished  tasks 
divided  by  the  total  time  for  all  tasks.  Next  step  is  to  add  range 
checking  (if  necessary) . 

function  Setppercent_complete(pl :  Project)  = 

size( [ttotal_time(tl)  |  (tl:  Task)  tl  in  ptask.set (pi)  & 
tstatus (tl)  =  ’finished])  =  0  — >  ppercent_complete(pl)  =  0.0; 

TRUE  — >  ppercent. complete (pi)  <- 
((reduce(+, [ttotal.time(tl)  I  (tl:  Task)  tl  in  ptask.set (pi)  & 
tstatus (tl)  =  ’finished]))/ 

(reduce(+, [ttotal.time (tl)  I  (tl:  Task)  tl  in  ptask.set (pi)] ) ) ) 

function  Getppercent.complete (pi :  Project):  real  = 
ppercent.complete (pi) 

function  Setpnumber.of .jobs (pi :  Project)  = 

TRUE  — >  pnumber.of .jobs (pi)  <-  size(pjob.set (pi) ) 

function  Getpnumber.of .jobs (pi :  Project):  integer  = 
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pnumber_of  _jobs  (pi) 

function  Setpnumber.of. tasks (pi :  Project)  = 

TRUE  — >  pnumber.of .tasks (pi)  <-  size (ptask.set (pi) ) 

function  Getpnumber.of .tasks (pi :  Project):  integer  = 
pnumber.of .tasks (pi) 

Vi  Finds  number  of  jobs  complete  through  the  tasks  in  the  taskset . 

Also  checks  to  determine  if  the  project  status  is  finished. 

function  Setpjobs_complete(pl :  Project)  = 

TRUE  — >  pjobs.complete(pl)  = 

size(*Cjl ( (jl :  Job)  jl  in  pjob.set(pl)  &  jstatus(jl)  =  ’finished}); 
pnumber.of _j obs (pi)  =  size({jl  I  (jl:  Job)  jl  in  pjob.set(pl)  & 
jstatus(jl)  =  ’finished})  — >  pjobs.complete(pl)  = 

size({j 1  !  (jl:  Job)  jl  in  pjob.set(pl)  &  jstatus(jl)  =  ’finished}); 
pjobs.complete(pl)  *  pnumber.of .jobs (pi)  — > 
ppercent.complete (pi)  *  1.0  &  pstatus(pl)  =  ’finished 

function  Getpjobs_complete(pl :  Project):  integer  = 
p j  obs. complete (pi ) 

Vi  Finds  the  number  of  tasks  complete  in  the  project  and  checks  if  the  project 
is  finished. 

function  Setptasks. complete (pi :  Project)  = 

TRUE  — >  ptasks.complete (pi)  = 

size ({tl | (tl :  Task)  tl  in  ptask.set(pl)  &  tstatus(tl)  =  ’finished}); 
pnumber.of .tasks (pi)  =  size({tl  I  (tl:  Task)  tl  in  ptask.set (pi)  & 
tstatus(tl)  =  ’finished})  — >  ptasks.complete (pi)  = 

size({tl  |  (tl:  Task)  tl  in  ptask.set (pi)  &  tstatus(tl)  =  ’finished}); 
ptasks.complete(pl)  =  pnumber.of .jobs (pi)  — > 
ppercent.complete (pi)  =  1.0  &  pstatus(pl)  =  ’finished 

function  Getptasks.complete (pi :  Project):  integer  = 
p j  obs. complete (pi ) 

Vi  Project  start  time  is  determined  by  the  lowest  task  start  time. 

function  SetpStart.Time(pl :  Project)  = 

TRUE  — >  pstart.time(pl)  <- 

t s t art . t ime ( arb ( { 1 1  !  (tl:  Task)  tl  in  ptask.set (pi)  & 

(f a(t2)  (t2  in  ptask.set (pi)  =>  tstart.time(tl)  <=  tstart_time(t2) ) )}) ) 

function  Getpstart.time (pi :  Project):  integer  = 
pstart.time(pl) 

Vi  Project  end  time  is  determined  by  the  last  task  end  time. 

function  Setpend.time (pi :  Project)  = 

TRUE  — >  pend.time(pl)  <- 

tend_time(  arb({tl  |  (tl:  Task)  tl  in  ptask.set (pi)  & 

(f a(t2)  (t2  in  ptask.set (pi)  =>  tend.time (tl)  >=  tend_time(t2) ) )}) ) 

function  Getpend.time(pl :  Project):  integer  = 
pend.time(pl) 

function  Setpwall.time (pi :  Project)  = 

TRUE  — >  pwall.time(pl)  =  pend.time(pl)  -  pstart.time(pl) 

function  Getpwall.time(pl :  Project):  integer  = 
pvall.time(pl) 

Vi  Project  total  time  is  based  on  the  tasks’  times. 

function  Setptotal.time(pl :  Project)  = 
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TRUE  — >  ptotal_time(pl)  <- 

reduce (+ ,  [ttotal.time(tl)  |  (tl:  Task)  tl  in  ptask_set (pi)] ) 

function  Getptotal_time(pl :  Project):  real  = 
ptotal_time(pl) 

Project  accuracy  is  based  on  the  tasks'  accuracies. 

function  SetpaccuracyCpl :  Project)  = 

TRUE  — >  paccuracy(pl)  <- 

real-to-nearest-integer (reduce (+, [t accuracy (t 1 ) | (tl :  Task)  tl  in  ptask_set (pi)] )/size (ptask_set (pi) ) ) 

function  Getpaccuracy (pi :  Project):  integer  = 
paccuracy (pi) 

function  Setptask_set (pi :  Project,  ts:  set (Task))  = 

ptask_set*  =  ptask.set (pi)  — >  ptask_set(pl)  =  ptask_set*  union  ts 

function  Getptask_set (pi :  Project):  set (Task)  = 
ptask_set (pi) 

function  Getpjob_set(pl:  Project):  set(Job)  = 

TRUE  — >  pjob_set(pl)  =  reduce(union,  {t job_set (tl)  I  (tl:  Task)  tl  in  ptask.set (pl)» ; 
pjob.set (pi) 

function  FindJob(pl:  Project,  jobname:  string): Job  = 

arb({j  | ( j : Job)  j  in  pjob.set(pl)  &  jname(j)  =  jobname}) 


n- 


End  of  Project 


! !  in-package (MRUn) 
!!  in-grammar ( 'user) 
#11 


—  Object  Name:  Qualif ied.For 

—  Specification  Date:  09/12/95 

—  Filename:  qualfor.re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Based  on:  Qualif ied_For  (950515) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  association  assignment 
Each  instance  represents  a  worker- job  link. 

—  History: 

—  09/05/95  (Hartrum):  original  design. 


I  I# 

■/,/,  Define  class  structure: 

var  Qualif ied_For :  object-class  subtype-of  user-object 

var  wqualif ied_f or :  map (Qualif ied_For,  Worker)  =  {||} 
var  jqualif ied_f or :  map(Qualif ied.For ,  Job)  =  {11} 
var  expect_accuracy :  map(Qualif ied_f or ,  integer)  =  {| |} 
var  expect_time:  map(Qualif ied_f or ,  integer)  =  {||} 

*/,*/,  Define  class  methods: 

function  NewQualif ied_For()  :  Qualif ied_For  = 
make-obj  ect ( ' Qualif ied_For) 

function  ZapQualif ied.For (qf :  Qualif ied_For)  * 
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erase-object (qf ) 


function  InitQualif ied.For (qf :  Qualif ied.For)  = 
NIL 

function  ShowQualif ied_For(qf :  Qualif ied_For)  = 
format  (TRUE,  M~\\pp\\  “7." ,  qf) 


The  next  six  functions  display  incremental  development  of  SetQualif ied.For . 
•///,  No  range  checks  just  assign 

function  SetQualif ied_For(qf :  Qualif ied.For ,  w:  Worker,  j:  Job,  ex.accuracy: 

integer,  ex.time:  integer)  = 

TRUE  — >  (wqualif ied.f or (qf )  =  w  &  jqualif ied_f or (qf )  =  j  & 

expect .accuracy (qf )  =  ex.accuracy  &  expect. time(qf)  =  ex.time) 

Check  af sc  and  skill  level  and  use  worker  and  job  attributes  to  establish 
qualif ied.fro  association's  expect.time  attribute  for  best.time  only. 

function  SetQualif ied.For2 (qf :  Qualif ied.For,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  >=  j skill. level(j )  — > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.for(qf)  =  j  &  expect.time (qf )  = 
jbest.time(j) ) 

Add  aver  age.  time  check  and  assignment, 
function  SetQualif ied_For3(qf :  Qualif ied.For ,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc.set(j)  &  wskill.level (w)  >  j skill_level( j )  — > 

(wqualif ied.f  or (qf )  =  w  k  jqualif ied.f or(qf)  =  j  &  expect _time(qf )  = 
jbest.time( j) ) ; 

wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  =  j skill_level( j )  > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or(qf)  =  j  &  expect _time(qf )  = 
javerage_time(j )) 

7,'/,  Add  worst.time  check  and  assignment. 

function  SetQualif ied_For4(qf :  Qualif ied.For ,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  >  jskill_level( j)  > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect.time (qf)  = 
jbest.time(j)) ; 

wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  =  jskill.level( j)  > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect.time (qf)  = 
javerage.time( j) ) ; 

wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  <  jskill_level( j)  > 

(wqualif ied.f or(qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect.time (qf)  = 
jworst.time(j) ) 

Add  qualif  ied.f  or  expect.accuracy  checks  and  assignments, 
function  SetQualif ied_For4a(qf :  Qualif ied.For ,  w:  Worker,  j:  Job)  = 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  >  j skill_level( j )  > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or(qf)  =  j  &  expect .time(qf)  = 
jbest_time( j)  &  expect.accuracy (qf)  =  jbest.accuracy(j)) ; 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  =  j skill_level( j )  --> 

(wqualif ied.f  or (qf )  =  w  &  jqualif ied.f or (qf)  =  j  &  expect.time (qf)  = 
j average.time ( j )  &  expect_accuracy(qf )  -  javerage_accuracy( j ) ) ; 
wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  <  j skill_level( j )  — > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect.time (qf)  = 
jbest.time ( j )  &  expect.accuracy (qf)  =  jworst. accuracy (j )) 

Added  axioms  to  allow  other  attributes  of  the  worker  and  job  to  affect  the 
expect.time  and  expect.accuracy  attributes  of  the  qualif ied.f or  association. 

function  SetQualif ied_For5(qf :  Qualif ied.For ,  w:  Worker,  j:  Job)  = 

'/,  Need  to  ensure  that  accuracy  <=  100  and  time  <=  besttime 
'/,  Could  easily  add  more  axioms  to  affect  the  expect.time  and 
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expect.accuracy  attributes 


wafsc(w)  in  jafsc_set(j)  &  wskill.level(w)  >  j skill. level(j )  — > 

(wqualif ied.f or (qf)  =  w  &  jqualif ied.f or (qf)  =  j  &  expect_time(qf )  = 
jbest.time(j )) ; 

wafsc(w)  in  jafsc.set(j)  &  wskill.level(w)  =  j skill. level( j )  > 

(wqualif ied_f or (qf)  =  w  k  jqualif ied.f or(qf)  =  j  &  expect.time (qf)  = 
javerage_time(j)) ; 

wafsc(w)  in  jafsc.set(j)  &  wskill_level(w)  <  j skill_level( j )  > 

(wqualif ied_f or (qf)  =  w  &  jqualif ied_f or(qf )  =  j  &  expect.time (qf)  = 
jbest_time( j)) ; 

wafsc(w)  in  jafsc.set(j)  &  weducation(w)  >=  10  &  j complexity (j )  <=  75  — > 
((expect .time*  =  expect.time(qf )  — >  expect.time (qf )  =  expect.time*  +  20)  & 
(expect.accuracy*  =  expect.accuracy (qf )  — >  expect.accuracy (qf )  = 
expect.accuracy*  +  20)) 

function  GetWQualif ied_For(qf :  Qualif ied.For) :  Worker  = 
wqualif ied.f or (qf) 

function  Get JQualif ied.For (qf :  Qualif ied.For) :  Job  = 
jqualif ied.f or (qf) 

function  GetExpect.Time(qf :  Qualif ied.For) :  integer  = 
expect.time (qf) 

function  GetExpect_Accuracy(qf :  Qualif ied.For) :  integer  = 
expect.accuracy (qf) 

7,7, - End  of  Qualif  ied.For  - 


! !  in-package ("RUM) 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  Qualif ied.ForSet 

—  Specification  Date:  09/12/95 

—  Filename:  qualf orset . re 

—  Specified  by:  Hibdon 

—  Based  on:  Qualif ied.For  (950515) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


II# 

7.7,  Define  base  sets  (types): 

Vi  Define  class  structure: 

var  Qualif ied.ForSet :  object-class  subtype-of  Container 

7.7.  Define  class  methods: 

function  NewQualif ied.ForSet ()  :  Qualif ied.ForSet  = 

make-object( ’Qualif ied.ForSet) 

function  InitQualif ied.ForSet (qf :  Qualif ied.ForSet)  = 
Init Cont  ainer ( qf ) 

function  ZapQualif ied.ForSet (qf :  Qualif ied.ForSet)  = 
erase-object (qf ) 

function  ShowQualif ied.ForSet (qf :  Qualif ied.ForSet)  = 
format  (TRUE,  n~\\pp\\  ~7.M ,  qf) 
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function  ListQualif  ied„ForSet  (qf :  Qualif ied_ForSet)  = 
enumerate  qset  over  range (contents (qf))  do 
format  (TRUE,  "~\\pp\\  "7,",  qset) 

7,7,  Given  a  job  and  a  qualif ied_forset ,  return  the  qualif ied_f or  association. 

Might  need  to  return  a  set  of  these. 

function  GetQualif ied_For(qs :  Qualif ied_ForSet ,  j:  Job):  Qualif ied_For  = 
arb({qf  |  (qf:  Qualif ied_For)  (qf  in  contents(qs)  & 
jname (Get JQualif ied.For (qf ) )  =  jname(j))}) 

7,7, - End  of  Qualif ied.ForSet  - 


! !  in-package ("RU") 
!!  in-grammar ( , user) 
#11 


—  Object  Name:  Qualif ied_0n 

—  Specification  Date:  09/12/95 

—  Filename:  qualif iedon. re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Must  compile  and  load  Tool,  Worker. 

—  Based  on:  Qualif ied_0n  (9204XX) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  qualified_on 
Each  instance  represents  a  tool-worker  link. 

—  History: 

—  09/12/95  (Hibdon) :  original  design. 


I  I# 

7.7,  Define  class  structure: 

var  Qualif ied_0n:  object-class  subtype-of  user-object 
var  tqualif ied_on:  map(Qualif ied_0n,  Tool)  =  {||} 
var  wqualif ied_on:  map (Qualif ied_0n,  Worker)  =  {11} 

7.7,  Define  class  methods: 

function  NewQualif ied_0n()  :  Qualified.On  = 
make-obj  ect ( ’ Qualif ied_0n) 

function  ZapQualif ied_0n(qo :  Qualif ied_0n)  = 
erase-object (qo) 

function  InitQualif ied_0n(qo :  Qualif ied_0n)  = 

NIL 

function  ShowQualif ied_0n(qo :  Qualif ied_0n)  = 
format  (TRUE,  n~\\pp\\  “7,",  qo) 

function  SetQualif ied_0n(qo :  Qualif ied_0n,  tl:  Tool,  w:  Worker)  = 

TRUE  — >  (tqualif ied_on(qo)  =  tl  &  wqualif ied_on(qo)  =  w) 

function  SetQualif ied_Qn(qo :  Qualif ied_0n,  tl:  Tool,  w:  Worker)  = 

wafsc(w)  in  toolaf sc_set (tl)  &  wskill_level(w)  >=  toolskill_level(tl)  --> 
(tqualif ied_on(qo)  =  tl  &  wqualif ied^on(qo)  =  w) 

function  GetTQualif ied_0n(qo :  Qualif ied_0n) :  Tool  = 
tqualified_on(qo) 


130 


function  GetWQualif  ied_0n(qo :  Qualif ied_0n) :  Worker  = 
vqualif ied_on(qo) 


•/.*/.- 


End  of  Qualified.Qn 


! !  in-package (nRUM) 
!!  in-grammar ( 5 user) 
#11 


—  Object  Name:  Qualif ied_ OnSet 

—  Specification  Date:  09/12/95 

—  Filename:  qualif iedonset . re 

—  Specified  by:  Hibdon 

—  Based  on:  Qualified.On  (950513) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


II# 

'/,'/,  Define  base  sets  (types): 

'///,  Define  class  structure: 

var  Qualif ied_ OnSet :  object-class  subtype-of  Container 

'/.'/,  Define  class  methods : 

function  NewQualif ied_0nSet ()  :  Qualif ied_0nSet  = 

make-object ( * Qualif ied.OnSet) 

function  InitQualif ied_0nSet (qo :  Qualif ied_ OnSet)  = 

InitContainer(qo) 

function  ZapQualif ied„0nSet (qo :  Qualif ied_0nSet)  = 
erase-object (qo) 

function  ShowQualif ied_0nSet (qo :  Qualif ied_0nSet)  = 
format (TRUE,  "~\\pp\\  "l",  qo) 

function  ListQualif ied_0nSet (qo :  Qualif ied_0nSet)  = 
enumerate  qoset  over  range (contents (qo) )  do 
format  (TRUE,  M~\\pp\\  "*/»",  qoset) 

function  GetQualif iedOnSet (ol :  Organization):  Set(<Worker,  Tool>)- 
{<tl,  w>  |  (tl:  Tool,  w:  Worker)  tl  in  contents (org-toolset (ol) )  & 
w  in  contents (org-workf orce (ol) )  &  wafsc(w)  in  toolaf sc.set (tl)  & 
wskill_level(w)  >=  toolskill_level(tl)}- 

*f*/t  Correctly  occupied  positions  based  on  afsc  only. 

function  GetAllQualif ied0n(ol :  Organization)  = 

fa(v:  Worker,  tl:  Tool)(v  in  worker_set(org-workforce(ol))  & 

tl  in  tool_set (org-toolset (ol) )  =>  AddQualif ied_0n(ol ,  tl,  w)) 

function  GetAllQualif ied0n(qs:  Qualif ied_0nSet) :  Set (Qualif ied.On)  = 

{qo  |  (qo:  Qualif ied_ On)  (qo  in  contents (qs)  &  waf sc(GetWQualif ied_0n(qo) ) 
in  toolaf sc_set (GetTQualif ied_0n(qo) ) )} 

function  SetPossibleQualif ied0n(ol :  Organization)  = 

fa(w:  Worker,  tl:  Tool)((w  in  contents (org-workf orce(ol) ) )  & 

(tl  in  contents (org-toolset (ol) ) )  =>  AddPossibleQualif ied_0n(ol ,  tl,  w)) 
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'/,*/,  Correctly  occupied  positions  based  on  afsc  and  skill  level, 
waf sc(GetWOccupy(occ) )  &  wskill_level(GetWOccupy(occ) )  >= 
posskill_level(GetPQccupy (occ) ) )} 

- End  of  Qualif ied_0nSet  - 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  Supports 

—  Specification  Date:  09/12/95 

—  Filename:  supports. re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Based  on:  Supports  (950511) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  association  supports 
Each  instance  represents  a  tool- job  link. 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


II# 


'/,'/,  Define  class  structure: 

var  Supports:  object-class  subtype-of  user-object 
var  tsupports:  map(Supports ,  Tool)  =  {11} 
var  jsupports:  map(Supports ,  Job)  =  {11} 
var  sup time:  map (Supports ,  integer)  =  {||} 
var  percentage:  map(Supports ,  integer)  =  {11} 

*/,'/,  Define  class  methods: 
function  NewSupports ()  :  Supports  = 
make-object ( *  Supports) 

function  ZapSupports (s :  Supports)  = 
erase-object (s) 

function  InitSupports (s :  Supports)  = 

NIL 

function  ShowSupports (s :  Supports)  = 
format  (TRUE,  "~\\pp\\  *7.'\  s) 

'/,'/,  Assumes  that  tool  supports  job. 

function  SetSupports(s :  Supports,  tl:  Tool,  j:  Job,  timel:  integer, 
percentl:  integer)  = 

TRUE  — >  (tsupports (s)  =  tl  &  j supports (s)  =  j  &  time(s)  =  timel  & 
percentage (s)  =  percentl) 

'/'/,  Checks  to  ensure  that  the  tool  can  support  the  job  through  the  intersection 
of  their  respective  afsc  sets. 

function  S et Support s (s :  Supports,  tl:  Tool,  j:  Job,  timel:  integer, 
percentl:  integer)  = 

toolaf sc_set (tl)  intersect  jaf sc.set ( j 1)  ~=  {}  — >  (tsupports(s)  =  tl  & 
j supports (s)  =  j  &  suptime (s)  =  timel  &  percentage (s)  =  percentl) 

function  GetTSupports(s :  Supports):  Tool  = 
tsupports(s) 
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function  Get Support sTime (s :  Supports):  Integer  = 
suptime (s) 

function  GetSupportsPercent (s :  Supports):  Integer  = 
percentage(s) 

function  Get JSupports (s :  Supports):  Job  = 
j support s(s) 


n- 


End  of  Supports 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 

#1  I 


—  Object  Name:  SupportsSet 

—  Specification  Date:  09/12/95 

—  Filename:  supportsset .re 

—  Specified  by:  Hibdon 

—  Based  on:  Supports  (950511) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon) :  original  design. 


I  I# 

'/,7,  Define  base  sets  (types)  : 

'///,  Define  class  structure: 

var  SupportsSet:  object-class  subtype-of  Container 

'/,'/,  Define  class  methods: 

function  NewSupportsSet ()  :  SupportsSet  = 
make-object ( * SupportsSet) 

function  InitSupportsSet (s :  SupportsSet)  = 

InitCont ainer ( s ) 

function  ZapSupportsSet (s :  SupportsSet)  = 
erase-object (s) 

function  ShowSupportsSet (s :  SupportsSet)  = 
format  (TRUE,  ,,-\\pp\\  *7." ,  s) 

function  ListSupportsSet (s :  SupportsSet)  = 
enumerate  sset  over  range (contents (s))  do 
format  (TRUE,  M~\\pp\\  *7." ,  sset) 

*/.'/•  Given  a  job  and  a  supportsset,  return  the  supports  association  that 
corresponds.  Might  need  to  return  a  set. 

function  GetSupports(ss :  SupportsSet,  j:  Job):  Supports  = 
arb({s  I  (s:  Supports)  (s  in  contents (ss)  & 
jname (Get JSupports (s))  =  jname(j))}) 


n- 


End  of  SupportsSet 


!  !  in-package ("RU") 
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!!  in-grammar ( ’user) 

#11 


—  Object  Name:  Task 

—  Specification  Date:  08/28/95 

—  Filename:  task. re 

—  Specified  by:  Hibdon 

—  Based  on:  Task  (950502) 

—  Design  Transforms  and  Rationale: 

—  History: 

--  08/28/95  (Hibdon):  original  design. 


II# 

'/,'/,  Define  base  sets  (types) : 

constant  JOB.STATUS  :  set(symbol)  =  {  ’ready,  ’waiting,  ’in-process,  ’finished} 

var  temptime:  integer  =  0 

var  tempjob:  Job  =  NewJobO 

'/,'/,  Define  class  structure: 

var  Task:  object-class  subtype-of  user-object 
var  tname :  map(Task,  string)  =  {||} 
var  tpriority:  map(Task,  integer)  *  {11} 
var  tstatus :  map (Task,  symbol)  =  {11} 
var  tinputs:  map(Task,  set(symbol))  =  {||} 
var  toutputs:  map(Task,  set(symbol))  =  {||} 
var  ttime_so_f ar :  map(Task,  real)  =  {11} 
var  tpercent  ..complete :  map(Task,  real)  =  {||} 
var  tnumber_of _jobs :  map(Task,  integer)  =  {||} 
var  t jobs_complete :  map(Task,  integer)  =  {11} 
var  tstart_time :  map(Task,  integer)  =  {11} 
var  tend.,  time :  map(Task,  integer)  =  {11} 
var  tvall_time:  map(Task,  integer)  =  {11} 
var  ttotal_time :  map(Task,  real)  =  { I  I } 
var  taccuracy:  map(Task,  integer)  =  { I  I } 
var  tjob_set:  map(Task,  set(Job))  =  { I  I } 

*/,'/,  Define  class  methods: 

function  NewTaskO  :  Task  = 
make-object ( ’Task) 

function  ZapTask(tl:  Task)  = 
erase-object (tl) 

function  ShowTask(tl:  Task)  = 

format  (TRUE,  "  Task  name:  "S~7,  Task  priority:  ~S~7,  status:  ~s~7.  inputs:  ~s~7, 
outputs:  ~s "'/,  time„so_far:  ~d~7.  percent_complete :  ~d~7.  number_of _jobs :  "d ~7, 
jobs_complete :  ~d*7.  start_time:  ~s~7,  end_time:  ~s~7,  wall.time:  ~d~7. 
total_time:  ~d  “'/,  accuracy:  "s  "7  job.set:  ~s~7.~7.~7." ,  tname  (tl),  tpriority(tl) , 
tstatus(tl),  tinputs(tl),  toutputs (tl) ,  ttime_so_f ar(tl) , 
tpercent ..complete (tl)  ,  tnumber_of _jobs(tl)  ,  t jobs_complete(tl) , 
tstart_t ime (t 1) ,  tend_time(tl) ,  twall_time(tl) ,  ttotal_time(tl) , 
taccuracy(tl) ,  tjob_set(tl)) 

function  Settname(tl:  Task,  n:  string)  = 

TRUE  — >  tname (tl)  =  n 

function  Gettname(tl:  Task):  string  = 
tname (tl) 

7,7.  Checks  boundary  ranges 
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function  Settpriority (tl :  Task,  p:  integer)  = 

(p  >=  0)  &  (p  <=  100)  — >  tpriority (tl)  =  p; 

(p  <  0)  OR  (p  >  100)  — >  (tpriority(tl)  =  undefined) 


function  Gettpriority(tl :  Task):  integer  = 
tpriority (tl) 

7,*/,  Manually  set  a  task’s  status 

function  Settstatus (tl :  Task)  = 

s  "in  J0B_STATUS  -->  tstatus(tl)  <-  undefined; 
s  in  JOB_STATUS  — >  tstatus(tl)  =  s 

function  Settstatus (tl :  Task)  = 

f a( j ) ( ( j  in  tjob.set(tl)  &  jstatus(j)  =  ’finished)  => 
tstatus (tl)  =  ’finished); 

fa(j) ( (j  in  t job_set (tl)  &  jstatus(j)  =  ’waiting)  => 
tstatus (tl)  =  ’waiting); 

f a( j) ( (j  in  t job_set (tl)  &  jstatus(j)  =  ’ready)  => 
tstatus(tl)  =  ’ready); 

ex(j)(j  in  t job_set (tl)  &  jstatus(j)  =  ’in-process)  => 
tstatus(tl)  <-  ’in-process 

7,7,  Refine  cannot  determine  how  to  do  the  following: 

7,  (s  "=  ’finished)  — >  (pc  <  100) 

7,  (ex  j  in  tjob.set (tl))  (jstatus(j)  "=  ’finished)  => 

7,  tstatus  (tl)  "=  ’finished 


7.7,  Derive  the  status  of  a  task  based  on  the  jobs  in  its  jobset. 
function  Gettstatus (tl :  Task):  symbol  = 

fa(j)((j  in  t job_set (tl)  &  jstatus(j)  =  ’finished)  => 

(tstatus (tl)  =  ’finished  &  ttime_so_f ar(tl)  =  Getttotal_time(tl))) ; 
fa(j)((j  in  tjob.set(tl)  &  jstatus(j)  =  ’waiting)  => 
tstatus(tl)  =  ’waiting); 

f a( j ) ( ( j  in  t job_set (tl)  &  jstatus(j)  =  ’ready)  => 
tstatus(tl)  =  ’ready); 

ex(j)(j  in  t job_set (tl)  &  jstatus(j)  -  ’in-process)  => 
tstatus (tl)  =  ’in-process; 
tstatus(tl) 

7.7.  Manually  set  inputs 

function  Settinputs (tl :  Task,  i:  set (symbol)  )  = 

TRUE  — >  t input s(tl)  =  i 

7.7,  Determines  the  inputs  and  outputs  of  a  task  based  on  the  jobs  in  its  jobset. 

function  SettI0(tl:  Task)  = 

TRUE  -->  tinputs(tl)  = 

arb(setdiff({j inputs (jl)  I  (jl:  Job)  jl  in  t job.set (tl)>, 

({j inputs (j 2)  |  (j2 :  Job)  j2  in  t job.set (tl)>  intersect 

{joutputs(j3)  I  (j3 :  Job)  j3  in  t job_set(tl)})) ) ; 

TRUE  — >  toutputs(tl)  = 

arb(setdiff({j outputs (jl)  |  (jl:  Job)  jl  in  tjob_set (tl)}, 

(•(j inputs (j2)  I  ( j 2 :  Job)  j2  in  t j ob.set (tl)>  intersect 

-[j  outputs  (j  3)  |  ( j  3  :  Job)  j3  in  t  j  ob_set  (tl)}) ) ) 

function  Gett input s (tl :  Task):  set(symbol)  = 
t inputs (tl) 

7.7.  Manually  set  outputs 

function  Settoutputs (tl :  Task,  o:  set (symbol))  = 

TRUE  — >  t output s(tl)  =  o 
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function  Gettoutputs (tl :  Task):  set(symbol)  = 
t outputs (tl) 

*/,*/,  Time  so  far  of  a  task  is  determined  by  the  amount  of  time  spent  so  far  on  the  jobs  in  its  jobset. 
*/,  Need  to  add  tstatus(tl)  =  ’ready  and  tstatus(tl)  =  waiting 

tstatus(tl)  =  ’finished  — >  ttime.so.f ar(tl)  <-  ttotal.time(tl) ; 
tstatus(tl)  =  ’in-process  — >  ttime_so_f ar(tl)  <- 
j start .time (arb ({j 1  I  ( j 1 :  Job)  jl  in  tjob_set(tl)  k  jstatus(jl)  = 

’in-process}))  *  jpercent_complete(arb({jl  1  (jl:  Job)  jl  in  tjob_set(tl)  k 
jstatus(jl)  =  ’in-process})) 

function  Getttime_so_f ar (tl :  Task):  real  = 
ttime.so.f ar(tl) 

%/*f%  This  function  calcualtes  percent  complete  based  on  the  number  of  jobs 
complete  divided  by  the  total  number  of  jobs.  Not  very  realistic. 

'/.function  Settpercent_complete(tl :  Task)  = 

'/,  size ({j  1  |  (jl:  Job)  jl  in  tjob_set(tl)  k  jstatus(jl)  =  ’finished})/ 

'/,  size(t job_set (tl))  >=  0.0  &  size({jl  I  (jl:  Job)  jl  in  tjob.set(tl)  & 

'/,  jstatus(jl)  =  *f  inished})/size(t  job_set  (tl))  <=  1.0  > 

'/,  tpercent_complete(tl)  -  size({jl  I  (jl:  Job)  jl  in  tjob.set(tl)  k 

*/,  jstatus(jl)  =  ’finished})/size(tjob_set(tl)) 

'/,'/,  Based  on  the  amount  of  time  spent  so  far  divided  by  the  total  amount  of  time 
for  all  jobs. 

function  Settpercent_complete(tl :  Task)  = 

TRUE  — >  tpercent ..complete (tl)  <- 
((reduce(+, Cjtime(jl)  I  (jl:  Job)  jl  in  tjob.set(tl)  & 
jstatus(jl)  =  ’finished]))/ 

(reduce(+, [jtime(jl)  I  (jl:  Job)  jl  in  tjob.set (tl)] )) ) 

function  Gettpercent_complete(tl :  Task):  real  = 
tpercent .complete (tl) 

function  Settnumber.of .jobs (tl :  Task)  = 

TRUE  — >  tnumber_of _jobs (tl)  <-  size (t job_set (tl) ) 

function  Gettnumber_of .jobs (tl :  Task):  integer  = 
tnumber.of _jobs(tl) 

function  Settjobs_complete(tl :  Task)  = 

TRUE  — >  t j obs.complete (tl)  = 

size({jl| (jl:  Job)  jl  in  tjob.set(tl)  &  jstatus(jl)  =  ’finished}); 
tnumber.of  .jobs  (tl)  =  size({jl  I  (jl:  Job)  jl  in  tjob.set(tl)  k 
jstatus(jl)  =  ’finished})  — >  t jobs. complete (tl)  = 

size ({j 1  I  (jl:  Job)  jl  in  tjob.set(tl)  k  jstatus(jl)  =  ’finished}); 
t jobs.complete(tl)  =  tnumber.of .j obs (tl)  — > 
tpercent.complete (tl)  =  1.0  k  tstatus(tl)  =  ’finished 

function  Gett jobs. complete (tl :  Task):  integer  = 
t j obs.complete (tl) 

function  SettStart_Time(tl :  Task)  = 

TRUE  — >  tstart.time(tl)  <- 
j  start  _time(arb(*Cj  1  |  (jl:  Job)  jl  in  tjob.set(tl)  & 

(fa(j2)  ( j2  in  tjob.set(tl)  =>  j start .time ( j 1)  <=  j start_time( j2) ) )}) ) 

function  Gettstart_time(tl :  Task):  integer  = 
tstart.time(tl) 
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function  Settend_time (tl :  Task)  = 

TRUE  — >  tend_time(tl)  <- 

jend.time(  arb(*[jl  I  (jl:  Job)  jl  in  tjob.set(tl)  & 

(fa(j2)  (j2  in  tjob.set(tl)  =>  j end. time (jl)  >=  jend_time( j2) ) )>) ) 

function  Gettend.timeCtl :  Task):  integer  = 
tend.time(tl) 

function  Settwall.time (tl :  Task)  = 

TRUE  — >  tvall.time(tl)  =  tend.time (tl)  -  tstart.time(tl) 

function  Gettwall.time(tl :  Task):  integer  = 
twall.time(tl) 

function  Setttotal.time (tl :  Task)  = 

TRUE  — >  ttotal.time(tl)  <- 

integer-to-real(reduce (+ ,  [jtime(jl)  l  (jl:  Job)  jl  in  t job.set (tl)] ) ) 

function  Getttotal.time(tl :  Task):  real  = 
ttotal.time(tl) 

function  Settaccuracy(tl :  Task)  = 

TRUE  — >  taccuracy(tl)  <- 

real-to-nearest-integer (reduce (+, [j accuracy (jl) I (jl :  Job)  jl  in 
t job.set (tl)] )/size(t job.set (tl))) 

function  Gettaccuracy(tl :  Task):  integer  = 
taccuracy(tl) 

function  SettJob.Set (tl :  Task,  js:  set(Job))  = 

t job.set*  =  t job.set (tl)  — >  tjob.set(tl)  =  tjob.set*  union  js 

function  Gett Job.Set (tl :  Task):  set(Job)  = 
tjob.set (tl) 

function  FindJob(tl:  Task,  jobname:  string): Job  = 

arb({j  | ( j : Job)  j  in  tjob.set(tl)  &  jname(j)  =  jobname}) 


End  of  Task 


!!  in-package ("RU") 
!!  in-grammar ( ’user) 

#!  I 


—  Object  Name:  Tool 

—  Specification  Date:  08/28/95 

—  Filename:  tool. re 

—  Specified  by:  Hibdon 

—  Based  on:  Tool  (950504) 

—  Design  Transforms  end  Rationale: 

—  History: 

—  08/28/95  (Hibdon):  original  design. 


II# 


*/,'/,  Define  base  sets  (types)  : 

constant  AFSCS  :  set  (string)  =  {  "33S3B" ,  "33S3C" ,  ,l4921,,> 
constant  STATUS.TYPE  :  set (symbol)  =  {  Jgo,  ’nogo} 

*/,'/,  Define  class  structure: 
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var  Tool:  object-class  subtype-of  user-object 
var  toolname:  map(Tool,  string)  =  {11} 
var  toolstatus:  map(Tool,  symbol)  =  {11} 
var  toolavailability :  map(Tool,  boolean)  =  {11} 
var  toolaf sc.set :  map(Tool,  set(string))  =  { I  I } 
var  toolskill.level :  map(Tool,  integer)  =  {11} 

7.7,  Define  class  methods: 

function  NewToolO  :  Tool  = 

make-obj  ect ( JTool) 

function  ZapTool(tl:  Tool)  = 
erase-object (tl) 

function  ShowTool(tl:  Tool)  = 

format  (TRUE,  11  Tool  name:  "S~7.  Status:  "s' 7.  Availability:  ~b~7.  Af sc.set:  "S"7. 
skill.level:  ~d~7."7,'7."7.M ,  toolname(tl) ,  toolstatus  (tl) ,  toolavailability(tl) , 
toolaf sc_set (tl) ,  toolskill.level(tl) ) 

function  Settoolname (tl :  Tool,  n:  string)  = 

TRUE  — >  toolname (tl)  =  n 

function  Gettoolname (tl :  Tool):  string  = 
toolname (tl) 

7.7,  Checks  for  valid  afsc. 

function  Settoolstatus (tl :  Tool,  s:  symbol)  = 
s  in  STATUS. TYPE  — >  toolstatus (tl)  =  s; 
s  "in  STATUS.TYPE  — >  toolstatus (tl)  =  undefined 

function  Gettoolstatus (tl :  Tool):  symbol  = 
toolstatus (tl) 

function  Settoolavailability(tl :  Tool,  a:  boolean)  = 

TRUE  — >  toolavailability(tl)  =  a 

function  Gettoolavailability(tl :  Tool):  boolean  = 
toolavailability (tl) 

function  Settoolaf sc. set (tl :  Tool,  aset:  set(string)  )  = 
aset  subset  AFSCS  — >  toolaf sc.set (tl)  =  aset 

function  Gettoolaf sc.set (tl :  Tool):  set(string)  = 
toolaf sc.set (tl) 

function  Settoolskill_level(tl :  Tool,  s:  integer)  = 

(s  >=  1  &  s  <=  9)  — >  toolskill.level(tl)  =  s 

function  Gettoolskill.level(tl :  Tool):  integer  = 
toolskill.level(tl) 

7.7,  - End  of  Tool  - 


! !  in-package ("RU") 
!!  in-grammar ( 5 user) 

#1  I 


—  Object  Name:  ToolSet 

—  Specification  Date:  09/11/95 

—  Filename :  toolset .re 

—  Specified  by:  Hibdon 

—  Based  on:  ToolSet  (950508) 

—  Design  Transforms  and  Rationale: 
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—  History: 

—  09/11/95  (Hibdon) :  original  design. 


II# 

'/,'/,  Define  base  sets  (types) : 

'/,*/,  Define  class  structure: 

var  ToolSet:  object-class  subtype-of  Container 

var  tool_readiness :  map(ToolSet,  real)  -  {II}' 
var  tool_set:  map(ToolSet,  set(Tool))  =  {11} 


*/,'/,  Define  class  methods: 

function  NewToolSetO  :  ToolSet  = 
make-object ( ’ ToolSet) 

function  InitToolSet (ts :  ToolSet)  = 

InitContainer ( t  s ) 

function  ZapToolSet (tsl :  ToolSet)  = 
erase-object (tsl) 

function  ShowToolSet (tsl :  ToolSet)  = 
format  (TRUE,  "ToolSet"'/,  tool.readiness :  ~d"7,  Tools:  "S"*/,"'/,"'/," , 
tool.readiness (tsl) ,  tool_set (tsl) ) 

'/,'/,  Determine  the  readiness  of  the  toolset  based  on  the  number  of  tools  in  the 
go  status  divided  by  the  number  of  tools  in  the  toolset . 

function  Settool_readiness(tsl :  ToolSet,  ol:  Organization)  = 

TRUE  — >  tool_readiness(tsl)  =  size({tl  I  (tl:  Tool)  tl  in 

contents (org-toolset (ol) )  &  toolstatus (tl)  =  ’go})/ 
size({tl  |  (tl:  Tool)  tl  in  contents (org-toolset (ol) )}) 

function  ListToolSet (ts :  ToolSet)  = 

enumerate  tl  over  range (contents (ts) )  do 

format  (TRUE,  M"\\pp\\  "7.",  GetToolName  (tl)  ) 

function  Gettool_readiness (tsl :  ToolSet):  real  - 
tool.readiness (tsl) 

function  SetToolSet (tsl :  ToolSet,  ts:  set(Tool))  = 

tool_set*  =  tool_set (tsl)  — >  tool_set (tsl)  =  tool_set*  union  ts 

7.'/. - End  of  ToolSet  - 


! !  in-package (MRUM) 
!!  in-grammar ( ’user) 

#1  i 


—  Object  Name:  Using 

—  Specification  Date:  09/12/95 

—  Filename:  using. re 

—  Specified  by:  Hibdon 

—  Dependencies: 

—  Based  on:  Using  (950512) 

—  Design  Transforms  and  Rationale: 

Associative  object  design  of  using 

Each  instance  represents  a  tool-worker  link. 
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—  History: 

—  09/12/95  (Hibdon) :  original  design. 


II# 


7,7#  Define  class  structure: 

var  Using:  object-class  subtype-of  user-object 
var  tusing:  map(Using,  Tool)  =  {11} 
var  vusing:  map (Using,  Worker)  =  {| 1} 

7,7#  Define  class  methods: 

function  NewUsingO  :  Using  = 
make-object ( 'Using) 

function  ZapUsing (u:  Using)  = 
erase-object (u) 

function  InitUsing(u:  Using)  = 

NIL 

function  ShowUsing(u:  Using)  = 
format  (TRUE,  M“\\pp\\  "7.'\  u) 

function  SetUsing(u:  Using,  tl:  Tool,  w:  Worker)  = 
TRUE  — >  (tusing(u)  =  tl  &  wusing(u)  =  w) 

function  GetTUsing(u:  Using) :  Tool  = 
tusing (u) 

function  GetWUsing(u:  Using):  Worker  = 
wusing(u) 


7.7.- 


End  of  Using 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  UsingSet 

—  Specification  Date:  09/12/95 

—  Filename:  usingset. re 

—  Specified  by:  Hibdon 

—  Based  on:  Using  (950512) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  09/12/95  (Hibdon):  original  design. 


I  I# 

7.7.  Define  base  sets  (types): 

7.7.  Define  class  structure: 

var  UsingSet:  object-class  subtype-of  Container 

7.7.  Define  class  methods: 

function  NewUsingSet ()  :  UsingSet  = 

make-object ( ’UsingSet) 

function  InitUsingSet (us :  UsingSet)  = 
InitContainer (us) 
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function  ZapUsingSet (us :  UsingSet)  - 
erase-object (us) 

function  ShowUsingSet (us :  UsingSet)  = 
format  (TRUE,  M“\\pp\\  “7," ,  us) 

function  ListUsingSet (us :  UsingSet)  = 

enumerate  uset  over  range (contents (us) )  do 
format(TRUE,  "~\\pp\\  ~7.M ,  uset) 

7,7. - End  of  UsingSet  - 


! !  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  Worker 

—  Specification  Date:  08/28/95 

—  Filename:  worker. re 

—  Specified  by:  Hibdon 

—  Based  on:  Worker  (950505) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  08/28/95  (Hibdon):  original  design. 


II# 

7.7.  Define  base  sets  (types) : 

constant  AFSCS  :  set (string)  =  {  "33S3B" ,  "33S3C",  "4921"} 

7.7.  Define  class  structure: 

var  Worker:  object-class  subtype-of  user-object 
var  wname:  map (Worker,  string)  =  {11} 
var  wafsc:  map(Worker,  string)  =  {||} 
var  wskill^level:  map(Worker,  integer)  =  {||} 
var  wavailability :  map(Worker,  boolean)  =  {||} 
var  wexperience:  map(Worker,  integer)  =  {||} 
var  weducation:  map(Worker,  integer)  =  {||} 
var  waptitude:  map(Worker,  integer)  =  {||} 

7.7.  Define  class  methods: 

function  NewWorkerO  :  Worker  = 

make-object ( ’ Worker) 

function  ZapWorker(w:  Worker)  = 
erase-object (w) 

function  ShowWorker(w :  Worker)  = 

format  (TRUE,  "  Worker  name:  ~S*7.  Afsc:  ~S~7,  skill.level:  ~d~7.  Availability: 
*b~7.  Experience:  ~d”7.  Education:  ~d~7»  Aptitude:  ~d~7.~7.~7." ,  wname (w)  , 
wafsc(w),  wskill_level(w) ,  wavailability (w) ,  wexperience (w) , 
weducation(w) ,  waptitude(w)) 

function  Setwname(w:  Worker,  n:  string)  = 

TRUE  — >  wname (w)  =  n 

function  Getwname(w:  Worker):  string  = 
wname (w) 

7.7.  Checks  for  valid  afsc 


141 


function  Setwafsc(v:  Worker,  a:  string)  = 
a  in  AFSCS  — >  wafsc(w)  =  a; 
a  "in  AFSCS  — >  wafsc(w)  =  undefined 

function  Getwafsc(v:  Worker):  string  = 
waf sc(w) 

Checks  boundary  ranges . 

function  Setwskill_level(w:  Worker,  s:  integer)  - 
(s  >=  1  &  s  <=  9)  — >  wskill_level(w)  =  s 

function  Getwskill_level(w:  Worker):  integer  = 
wskill_level(w) 

function  Setwavailability(w:  Worker,  a:  boolean)  = 
TRUE  — >  wavailability (w)  =  a 

function  Getwavailability(w :  Worker):  boolean  = 
wavailability (w) 

7,7.  Checks  boundary  ranges. 

function  Setwexperience(w:  Worker,  e:  integer  )  = 
(e  >=  0  &  e  <=  30)  — >  wexperience(w)  =  e 

function  Getvexperience(w:  Worker):  integer  = 
wexperience(w) 

7,7.  Checks  boundary  ranges. 

function  Setweducation(w :  Worker,  e:  integer)  = 

(e  >=  0  &  e  <=  18)  — >  weducation(w)  =  e 

function  Getweducation(w :  Worker):  integer  = 
weducation(w) 

7,7.  Checks  boundary  ranges. 

function  Setwaptitude (w:  Worker,  a:  integer)  = 

(a  >=  0  &  a  <=  100)  — >  waptitude(w)  =  a 

function  Getwaptitude(w:  Worker):  integer  = 
waptitude(w) 


End  of  Worker 


!!  in-package ("RU") 
!!  in-grammar ( ’user) 
#11 


—  Object  Name:  Workforce 

—  Specification  Date:  09/11/95 

—  Filename:  workforcel .re 

—  Specified  by:  Hibdon 

—  Based  on:  Worker  (950509) 

—  Design  Transforms  and  Rationale: 

—  History: 

—  08/28/95  (Hibdon) :  original  design. 


!  I# 

7.7,  Define  base  sets  (types): 

7.7.  Define  class  structure: 
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var  Workforce:  object -class  subtype-of  Container 

var  workf orceuse :  map(Workf orce ,  string)  =  {||} 
var  f orce.readiness :  map(Workf orce ,  real)  =  {||} 
var  worker_set:  map(Workf orce ,  set(Worker))  =  {||} 

*/,*/,  Define  class  methods: 

function  NewWorkf orce ()  :  Workforce  = 

make-object ( ’Workforce) 

function  InitWorkf orce(wf :  Workforce)  = 

InitContainer (wf ) 

function  ZapWorkf orce(wf :  Workforce)  = 
erase-object (wf ) 

function  ShowWorkf orce(wf :  Workforce)  = 
format  (TRUE,  "Workforce"*/,  f  orce.readiness  :  ~d Workers:  "S"*/,"'/,"*/,"  , 
force_readiness(wf ) ,  worker.set (wf ) ) 

*/*{  Force  readiness  is  the  number  of  correctly  occupied  positions  in  the  manning 
plan  divided  by  the  total  number  of  positions  in  the  manning  plan. 

function  Setf orce.readiness (wf :  Workforce,  oi:  Organization,  mp:  ManningPlan)  = 
TRUE  -->  f orce_readiness (wf )  = 

size(GetCorrectly0ccupiedPositions2(org-occupy(ol) ) ) / size (positions (mp) ) 

function  Getf orce_readiness (wf :  Workforce):  real  = 
f orce_readiness (wf ) 

function  Setworkerset (wf :  Workforce,  ws:  set (Worker))  = 

worker_set*  =  worker.set (wf )  — >  worker_set(wf )  =  worker.set*  union  ws 

function  SetWorkf orceUse (wf :  Workforce,  s_use:  string)  = 

TRUE  — >  workf orceuse (wf )  =  s_use 

function  GetWorkf orceUse (wf :  Workforce):  string  = 
workf orceuse (wf) 

function  GetAllWorkers(wf :  Workforce):  set (Worker)  = 
range (contents (wf)) 

function  ListWorkf orce(wf :  Workforce)  = 
enumerate  wl  over  range (contents (wf))  do 
format  (TRUE,  ""WppW  GetWName(wl) ) 

function  GetWorker (wf :  Workforce,  tempname:  string):  Worker  = 

arb({x  |(x:Worker)  x  in  range ( cont ent s (wf) )  &  wname(x)  =  tempname}) 

'///, - End  of  Workforce  - 


143 


Bibliography 


1.  “The  Handbook  of  Artificial  Intelligence,”  IV  (1989). 

2.  Balzer,  Robert,  et  al.  “Software  Techmology  in  the  1990’s:  Using  a  New  Paradigm,”  IEEE 
Computer ,  16-22  (November  1983). 

3.  Bandinelli,  Sergio,  et  al.  “Modeling  and  Improving  an  Industrial  Software  Process,  IEEE 
Transactions  on  Software  Engineering,  21  (5):440-453  (May  1995). 

4.  Bjork,  Jim.  “Screening  for  Success,”  Texas  Banking,  82(11)  (November  1993). 

5.  Blaine,  Lee,  et  al.  Specware™  User  Manual,  October  1994.  Specware™Version  Core4. 

6.  Borman,  V/.,  et  al.  Productive  Capacity:  The  Concept ,  Research ,  and  Applications.  Technical 
Report  AL/HR-TP-1994-0021,  Brooks  AFB,  TX  78235-5601:  Human  Resources  Directorate, 
August  1994. 

7.  Choi,  Dong,  et  al.  Systems  Modeling.  Technical  Report  NAVSWC  TR  91-592,  Silver  Spring, 
Maryland  20903-5000:  Naval  Surface  Warfare  Center,  February  1992. 

8.  Faneuff,  Robert  S.  Predicting  the  Productive  Capacity  of  Air  Force  Aerospace  Ground  Equip¬ 
ment  Personnel  Using  Aptitude  and  Experience  Measures.  MS  thesis,  AFIT/GOR/ENS/93M- 
05,  1993. 

9.  Hall,  Anthony.  “Seven  Myths  of  Formal  Methods,”  IEEE  Software,  11-19  (September  1990). 

10.  Hartrum,  Thomas  C.,  “CSCE  594  -  Object-Oriented  Design  and  Analysis.’  Class  Notes,  1993. 

11.  Hartrum,  Thomas  C.,  et  al.  “Modeling  Wing  Level  Operations  Using  Formal  Object  Models.” 
National  Aerospace  and  Electronics  Conference  Proceedings.  NAECON,  May  1995. 

12.  Hunt,  Captain  Robert  J.  Modeling  Operational  Task  Assignment  in  Air  Force  Wing  Command 
and  Control.  AD-A289319,  Graduate  School  of  Engineering,  Air  Force  Institute  of  Technology 
(AU),  1994. 

13.  Huo,  Y.  Paul  and  Jack  Kearns.  “Optimizing  the  Job-person  Match  with  Computerized  Human 
Resource  Information  Systems,”  Personnel  Review,  24(2):3-18  (1992). 

14.  Kavanaugh,  Michael  J.,  et  al.  Job  Performance  Measurement  in  the  Military:  A  Classification 
Scheme,  Literature  Review,  and  Directions  for  Research.  Technical  Report  AFHRL-TR-87- 
15,  AFSC  Brooks  AFB,  TX  78235-5601:  Air  Force  Human  Resources  Laboratory,  September 
1987. 

15.  Kralji,  Mary  M.,  et  al.  Definition  and  Measures  of  Induvidual  and  Unit  Readiness  and  Fam¬ 
ily  Phenomena  Affecting  it.  Technical  Report  91-32,  Research  Triangle  Park,  NC:  Research 
Triangle  Institute,  February  1991. 

16.  Kusiak,  Andrew,  et  al.  “Reengineering  of  Design  and  Manufacturing  Processes,”  Computers 
and  Industrial  Engineering,  (3): 521-536  (July  1994). 

17.  Langloss,  Randel  K.  Knowledge  Based  Software  Engineering  (KBSE)  Support:  A  Formal 
Model  of  Wing-Level  C2  Applied  to  the  432nd  Fighter  Wing  Misawa  AB,  Japan.  Technical 
Report,  HQ  PACAF/SCC,  June  14,  1993. 


144 


18.  Leonhard,  Corey  A.  and  J  Steve  Davis.  “Job-Shop  Development  Model:  A  Case  Study,”  IEEE 
Software,  12( 2):86-92  (March  1995). 

19.  Lichter,  Horst,  et  al.  “Prototyping  in  Industrial  Software  Projects-Bridging  the  Gap  Between 
Theory  and  Practice,”  IEEE  Transactions  on  Software  Engineering,  20(ll):825-832  (Novem¬ 
ber  1994). 

20.  Lowry,  Michael  R.  “Software  Engineering  in  the  Twenty-First  Century.”  Automating  Software 
Design,  edited  by  Michael  R.  Lowry  and  Robert  D.  McCartney.  627-654.  Menlo  Park,  CA: 
AAAI  Press,  1991. 

21.  Lung,  C.,  et  al.  “Computer  Simulation  Software  Reuse  by  Generic/Specific  Domain  Model¬ 
ing  Approach,”  International  Journal  of  Software  Engineering  and  Knowledge  Engineering , 
^  (1) :81— 102  (mar  1994). 

22.  McCain,  Ron.  “Reusable  Software  Component  Construction:  A  Product-Oriented  Paradigm,” 
AIAA/ ACM/N AS  A/IEEE  Computers  in  Aerospace  V  Conference,  125-135  (October  1985). 

23.  McDowell,  Phillip  W.  and  David  W.  Morgan.  Business  Process  Improvement  Applied  to  Writ¬ 
ten  Temporary  Duty  Travel  Orders  within  the  United  States  Air  Force.  MS  thesis,  Graduate 
School  of  Logistics  and  Acquisition  Management,  Air  Force  Institute  of  Technology  (AU), 
December  1993. 

24.  Place,  Patrick  R.  H.  and  William  G.  Wood.  Formal  Development  of  Ada  Programs  Using 
Z  and  Anna:  A  Case  Study.  Technical  Report  SEI-91-TR-1,  Carnegie  Mellon  University, 
Pittsburgh,  Pennsylvania  15213:  Software  Engineering  Instute,  February  1991. 

25.  Prieto-Diaz,  Ruben.  “Domain  Analysis  for  Reusability.”  Domain  Analysis  and  Software  Sys¬ 
tems  Modeling  edited  by  Guillermo  Arango  and  Ruben  Prieto-Diaz,  63-69,  IEEE  Computer 
Society  Press,  1991. 

26.  Reasoning  Systems  Inc.,  3260  Hillview  Avenue,  Palo  Alto,  CA.  Refine  User  s  Guide,  May 
1990.  Version  3.0. 

27.  Rumbaugh,  J.,  et  al.  Object-Oriented  Modeling  and  Design.  Prentice-Hall,  Inc.,  1991. 

28.  Sarchet,  Captain  Michael  D.  Modeling  Workload  Effectiveness  and  Efficiency  of  Air  Force 
Wing  Command  and  Control.  AD-A289217,  Graduate  School  of  Engineering,  Air  Force  Insti¬ 
tute  of  Technology  (AU),  1994. 

29.  Spivey,  J.M.  The  Z  Notation.  London:  Prentice  Hall  International,  1989. 

30.  Tracz,  Will.  “Domain  Analysis  Working  Group  Report-  First  International  Workshop  on 
Software  Reusability,”  ACM  SIGSOFT  Software  Engineering  Notes,  17:27-34  (July  1992). 

31.  Wabiszewski,  Kathleen  May.  Unification  of  Larch  and  Z-Based  Object  Models  to  Support 
Algebraically-Based  Design  Refinement:  The  Z  Perspective.  AD-A289234,  Graduate  School  of 
Engineering,  Air  Force  Institute  of  Technology,  December  1994. 

32.  Warner,  Russel  M.  A  Method  for  Populating  the  Knowledge  Base  of  AFIT’s  Domain  Oriented 
Application  Composition  System.  MS  thesis,  AFIT/GCS/ENG/93D-24,  Graduate  School  of 
Engineering,  Air  Force  Institute  of  Technology  (AETC),  Wright-Patterson  AFB,  OH,  December 
1993  (AD-A274128). 


145 


33.  Welgan,  Robert  L.  Domain  Analysis  and  Modeling  of  a  Model-Based  Software  Executive.  AD- 
A274087,  Graduate  School  of  Engineering,  Air  Force  Institute  of  Technology,,  Wright-Patterson 
AFB,  Ohio,  December  1993. 


146 


Vita 


Captain  Vincent  S.  Hibdon  was  born  August  8,  1964,  in  Oklahoma  City,  Oklahoma,  and 
graduated  from  East  Central  High  School,  Tulsa,  Oklahoma,  in  May  1982.  On  July  7,  1987,  Vince 
enlisted  in  the  US  Air  Force.  Upon  graduation  from  Basic  Military  Training  School,  Vince  was 
sent  to  Keesler  AFB,  Mississippi,  where  he  completed  Avionics  Communications  Systems  training 
and  was  stationed  for  his  first  assignment  as  a  Communication-Navigation  Systems  Maintenance 
technician  working  on  C-130  aircraft.  While  stationed  at  Keesler  AFB,  Vince  was  accepted  into  the 
Airman’s  Education  and  Commissioning  Program  to  complete  his  Bachelor  of  Science  in  Computer 
Science  at  the  Univeristy  of  Missouri-Rolla.  Graduation  from  UMR  led  Vince  to  Officer  Training 
School.  Vince  became  Second  Lieutenant  Hibdon  on  September  25,  1991  and  returned  to  Keesler 
AFB  to  complete  Basic  Communication-Computer  Officer  Training. 

Upon  graduation  from  the  Communication- Computer  Systems  Officer  Core  course  at  Keesler 
AFB,  Mississippi,  in  March,  1992,  Lt  Hibdon  was  assigned  to  the  552nd  Air  Control  Wing.  His 
duties  there  included  the  support  and  operational  testing  of  Airborne  Warning  and  Control  Systems 
(AWACS)  software.  In  May  1994,  Lt  Hibdon  entered  the  Air  Force  Institute  of  Technology  (AFIT) 
at  Wright-Patterson  AFB,  Ohio,  to  pursue  a  Master  of  Science  degree  with  a  Computer  Science 
major  and  concentration  in  Software  Engineering.  Upon  graduation  from  AFIT  in  December  1995, 
Captain  Hibdon  was  re-assigned  to  Global  Weather  Central,  Offutt  AFB,  Nebraska. 


Permanent  address:  2727  S.  116th  East  Place. 

Tulsa,  OK  74129 


147 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,andtotheOfficeof  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0 188),  Washington,  DC  20503. 

1.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE  3.  REPORT.  TYPE  AND  DATES  COVERED 

December  1995  Technical  Report;  Thesis 

4.  TITLE  AND  SUBTITLE 

AN  OBJECT-ORIENTED,  FORMAL  METHODS  APPROACH  TO  ORGANIZATIONAL 

PROCESS  MODELING 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S) 

Captain  Vincent  S.  Hibdon 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADORESS(ES) 

Air  Force  Institute  of  Technology,  WPAFB  OH  45433-6583 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

AFIT/GCS /ENG/95D-06 

9.  SPONSORING  /MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

HQ  PACAF 

25  E  Street,  Suite  C-206 

Hickam  AFB,  HI  96853 

10.  SPONSORING /MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 

Approved  for  public  release;  Distribution  Unlimited 

12b.  DISTRIBUTION  CODE 

13.  ABSTRACT  (Maximum  200  words) 

This  document  presents  a  methodology  for  developing  an  organizational  process  model  which  is  based  on  the 
principles  of  object-oriented  design  and  formal  software  engineering  methods.  The  methodology  begins  with 
the  development  of  an  object-oriented  Rumbaugh  model.  The  Rumbaugh  model  is  then  formally  specified 
in  Z  (Zed)  schemas.  Finally,  the  Z  specifications  are  translated  into  an  executable  model  in  the  Software 
Refinery  Environment™.  This  model  is  described  based  on  the  AF  wing  domain  and  developed  in  this  domain. 
The  proposed  methodology  is  then  shown  to  produce  a  very  general  model  which  is  extendable  across  almost 
any  domain.  The  proposed  methodology  is  also  shown  to  be  very  general  and  tailorable  for  specific  domain 
applications. 

14.  SUBJECT  TERMS 

Object-Oriented,  Formal  Methods,  Process  Model 

15.  NUMBER  OF  PAGES 

157 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 

OF  REPORT 

UNCLASSIFIED 

18.  SECURITY  CLASSIFICATION 

OF  THIS  PAGE 

UNCLASSIFIED 

19.  SECURITY  CLASSIFICATION 

OF  ABSTRACT 

UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

UL 

NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  Z39-18 
298-102 


GENERAL  INSTRUCTIONS  FOR  COMPLETING  SF  298 


The  Report  Documentation  Page  (RDP)  is  used  in  announcing  and  cataloging  reports.  It  is  important 
that  this  information  be  consistent  with  the  rest  of  the  report,  particularly  the  cover  and  title  page. 
Instructions  for  filling  in  each  block  of  the  form  follow.  It  is  important  to  stay  within  the  lines  to  meet 
optical  scanning  requirements. 


Block  1 .  Aqencv  Use  Only  (Leave  blank 


Block  2.  Report  Date.  Full  publication  date 
including  day,  month,  and  year,  if  available  (e.g.  1 
Jan  88).  Must  cite  at  least  the  year. 

Block  3.  Tvoe  of  Report  and  Dates  Covered. 


State  whether  report  is  interim,  final,  etc.  If 
applicable,  enter  inclusive  report  dates  (e.g.  10 
Jun  87  -  30  Jun  88). 

Block  4.  Title  and  Subtitle.  A  title  is  taken  from 


the  part  of  the  report  that  provides  the  most 
meaningful  and  complete  information.  When  a 
report  is  prepared  in  more  than  one  volume, 
repeat  the  primary  title,  add  volume  number,  and 
include  subtitle  for  the  specific  volume.  On 
classified  documents  enter  the  title  classification 
in  parentheses. 

Block  5.  Funding  Numbers.  To  include  contract 
and  grant  numbers;  may  include  program 
element  number(s),  project  number(s),  task 
number(s),  and  work  unit  number(s).  Use  the 
following  labels: 


Contract 

PR  - 

Project 

Grant 

TA  - 

Task 

Program 

WU  - 

Work  Unit 

Element 

Accession  No 

Block  6.  Author(s).  Name(s)  of  person(s) 
responsible  for  writing  the  report,  performing 
the  research,  or  credited  with  the  content  of  the 
report.  If  editor  or  compiler,  this  should  follow 
the  name(s). 

Block  7.  Performing  Organization  Name(s)  and 


Address(es).  Self-explanatory. 

Block  8.  Performing  Organization  Report 


Number.  Enter  the  unique  alphanumeric  report 
number(s)  assigned  by  the  organization 
performing  the  report. 

Block  9.  Soonsoring/Monitorino  Aqencv  Name(s) 


and  Address(es).  Self-explanatory. 

Block  10.  Sponsorinq/Monitorinq  Aqencv 
Report  Number.  (If  known) 

Block  11.  Supplementary  Notes.  Enter 
information  not  included  elsewhere  such  as: 
Prepared  in  cooperation  with...;  Trans,  of...;  To  be 
published  in....  When  a  report  is  revised,  include 
a  statement  whether  the  new  report  supersedes 
or  supplements  the  older  report. 


Block  12a.  Distri bution/Avaiiabi I ity  Statement. 


Denotes  public  availability  or  limitations.  Cite  any 
availability  to  the  public.  Enter  additional 
limitations  or  special  markings  in  all  capitals  (e.g. 
NOFORN,  REL,  ITAR). 


See  DoDD  5230.24,  "Distribution 
Statements  on  Technical 
Documents." 

See  authorities. 

See  Handbook  NHB  2200.2. 

Leave  blank. 


DOE 

NASA 

NTIS 


Block  12b.  Distribution  Code. 


NASA- 
NTIS  - 


Leave  blank. 

Enter  DOE  distribution  categories 
from  the  Standard  Distribution  for 
Unclassified  Scientific  and  Technical 
Reports. 

Leave  blank. 

Leave  blank. 


Block  13.  Abstract.  Include  a  brief  (Maximum 
200  words)  factual  summary  of  the  most 
significant  information  contained  in  the  report. 

Block  14.  Subject  Terms.  Keywords  or  phrases 
identifying  major  subjects  in  the  report. 

Block  15.  Number  of  Pages.  Enter  the  total 


number  of  pages. 

Block  16.  Price  Code.  Enter  appropriate  price 
code  (NTIS  only). 

Blocks  17.  - 19.  Security  Classifications.  Self- 
explanatory.  Enter  U.S.  Security  Classification  in 
accordance  with  U.S.  Security  Regulations  (i.e., 
UNCLASSIFIED).  If  form  contains  classified 
information,  stamp  classification  on  the  top  and 
bottom  of  the  page. 

Block  20.  Limitation  of  Abstract.  This  block  must 


be  completed  to  assign  a  limitation  to  the 
abstract.  Enter  either  UL  (unlimited)  or  SAR  (same 
as  report).  An  entry  in  this  block  is  necessary  if 
the  abstract  is  to  be  limited.  If  blank,  the  abstract 
is  assumed  to  be  unlimited. 


*  U.S.GPO:  1 993-0-336-043 


Standard  Form  298  Back  (Rev.  2-89) 


